ARTA TESTĂRII SOFTWARE ARTA TESTĂRII SOFTWARE GL ENFORD J MYERS O publicație Wiley—Interscience John Wiley & Sons New York • Chichester • Brisbane • Toronto G Myers Traducere din engleză, editată de B A Pozin Moscova „Finanțe și statistică” BBK M KP Traducători: S A Blau, S G Orlov, B A Pozin, L S Chernyak PGISH Bimiatvi lor Gorki - -^ Myers G M Arta testării software-ului / Per din engleză, ed B A Pozina - M : Finanţe şi statistică, - p , ill k Cartea prezintă în linii mari și destul de popular principiile de bază ale metodologiei de testare și depanare a programelor Sunt luate în considerare problemele de psihologie și economia testării Un loc semnificativ este acordat metodelor de ajustare a programelor Pentru profesioniștii implicați în programare, studenții și studenții absolvenți care studiază computerele — BBK M - — ( )— Ф ©John Wiley & Sons, Inc , © Traducere în rusă, prefață, „Finanțe și statistică”, PREFAȚĂ LA EDIȚIA RUSĂ Cartea lui G Myers „Arta testării programelor” este dedicată unei secțiuni importante și în dezvoltare rapidă a tehnologiei moderne de programare Această carte poate fi considerată ca un manual de testare și depanare, conceput pentru o gamă largă de specialiști de diverse calificări implicați în dezvoltarea programelor de calculator Principalul său avantaj este prezentarea sistematică a metodelor de testare a programelor și de pregătire a testelor software Materialul este ilustrat cu un număr mare de exemple care contribuie la dezvoltarea practică a metodelor de testare Conceptele procesului de programare și obiectul său de dezvoltare - programele s-au schimbat calitativ în ultimul deceniu Producția de programe a căpătat un caracter de masă, volumul și complexitatea lor medii au crescut semnificativ Dezvoltarea sistemelor software a necesitat eforturi semnificative ale unor mari echipe de specialişti Programele au încetat să fie doar computaționale și au început să îndeplinească cele mai importante funcții de gestionare și prelucrare a informațiilor în diverse sectoare ale economiei naționale Acestea și o serie de alte circumstanțe au condus la o schimbare fundamentală în abordarea programelor Complexele software nu mai sunt considerate doar ca rezultat al creativității științifice și al artei Abordarea programelor ca un obiect care este o consecință a unui proces tehnologic complex și a unui produs software a devenit dominantă A fost nevoie să se determine calitatea acestui produs și costurile cu forța de muncă pentru a atinge nivelul de calitate cerut Nevoia a crescut de metode și instrumente care să ofere o combinație de înaltă calitate a produsului software creat cu perioade scurte de dezvoltare și suficiente cinci productivitate ridicată a echipelor de specialişti Crearea de complexe software pentru gestionarea obiectelor și proceselor tehnologice, precum și pentru prelucrarea informațiilor în timp real, capătă treptat caracterul de producție industrială Ca urmare, rolul tehnologiei de dezvoltare software și al diverselor mijloace de susținere a procesului tehnologic de proiectare a acestora crește Componentele tehnologice includ regulile și metodele de organizare a echipelor de proiectare; mijloace de suport metodologic al procesului de proiectare - instructiuni de programare, depanare, documentare si testare a programelor; mijloace de suport instrumental și de automatizare a proceselor Toate aceste instrumente fac posibilă unificarea dezvoltării componentelor software individuale și asigurarea integrării lor reciproce în complexe software ordonate structural cu o sarcină țintă specifică În același timp, este posibilă o utilizare echilibrată a resurselor de calcul ale computerului pentru rezolvarea unor probleme particulare, pentru a rezolva cât mai eficient problema principală țintă a acestui pachet software Dezvoltarea și aplicarea tehnologiilor de proiectare a pachetelor software duce la necesitatea de a măsura și compara eficacitatea acestora, în primul rând din punct de vedere al gradului de influență asupra calității produsului software Indicatorii de calitate ai programului sunt supuși măsurării și evaluării numerice, pentru care se formalizează prin introducerea metricilor corespunzătoare Aplicarea de metrici la pachetele software vă permite să eficientizați dezvoltarea, testarea, operarea și întreținerea acestora Interacțiunea dintre dezvoltator și client (sau utilizator) devine mai clară, iar calitatea programelor poate fi cuantificată Asigurarea calității înalte a pachetelor software complexe este asociată cu costuri semnificative ale forței de muncă pentru dezvoltatori Productivitatea medie a muncii a programatorilor practic nu a crescut în ultimii ani și rămâne aproximativ la nivelul anilor , în ciuda îmbunătățirii tehnologiei de programare Acest lucru se datorează creșterii continue a complexității sistemelor software, drept urmare costul dezvoltării unei comenzi într-un program este aproape neschimbat nyatsya Costul creării programelor crește rapid odată cu creșterea cerințelor de calitate Prin urmare, sarcina de a determina relația dintre complexitatea dezvoltării și diverși indicatori de calitate vine în prim-plan Se dovedește că pentru seturi complexe de programe este foarte dificil să se obțină o calitate înaltă a funcționării, iar după asigurarea performanței generale, poate dura ani de muncă pentru a obține programe cu indicatorii de calitate necesari O eroare aparent nesemnificativă poate degrada drastic performanța unui program, cum ar fi fiabilitatea acestuia, iar în unele cazuri trebuie depuse eforturi mari pentru a detecta și elimina această eroare Prin urmare, deja în prezent sunt necesare metode și mijloace care să permită îmbunătățirea semnificativă a calității programelor la costuri relativ scăzute ale forței de muncă Testarea este una dintre cele mai intense etape de dezvoltare a programului (intensitatea muncii sale este de la la % din intensitatea totală a muncii) În plus, ponderea costului său în costul total al programelor tinde să crească odată cu creșterea complexității pachetelor software și creșterea cerințelor pentru calitatea acestora Cu toate acestea, relativ puțină atenție este acordată procesului de depanare în literatura științifică și educațională despre programare Acest lucru poate fi explicat parțial prin experiența insuficientă în acest domeniu pentru generalizări și, parțial, prin tradițiile în teoria și practica programării, conform cărora accentul principal este pus pe limbajele de programare și mijloacele de traducere a programelor Cartea propusă de G Myers oferă o serie de recomandări metodologice pentru programele de depanare Autorul subliniază că testarea este încă în mare măsură o artă Cartea rezumă experiența acumulată în acest domeniu, se elaborează metode de testare, se notează modalități de automatizare a unor astfel de lucrări, iar atenția se concentrează pe arta de a testa în principal grupuri relativ mici și programe autonome Aceasta este o zonă foarte semnificativă a tehnologiei de dezvoltare a software-ului, iar recomandările date sunt deosebit de utile pentru o gamă largă de specialiști care nu au stăpânit încă tehnicile moderne de depanare Aș dori să recomand cititorilor sovietici să încerce să vadă dincolo de recomandările din „art stve” o anumită știință și principii de construcție a mijloacelor de automatizare a proceselor tehnologice Acest lucru este deosebit de important de luat în considerare nu numai în dezvoltarea de programe unice mici, ci și în producția în masă a programelor de complexitate diferită, supuse unei replicări și întreținere largi de mulți ani În acest din urmă caz, este necesară stabilirea unui proces tehnologic reglementat și controlat folosind, în special, recomandările cărții lui G Myers Recomandările selectate pot fi traduse în categoria regulilor tehnologice obligatorii, a căror implementare este recomandabil să fie controlată automat Atunci când se dezvoltă o tehnologie de proiectare a unui program, ar trebui să se identifice în mod clar un anumit număr (dacă este posibil, nu foarte mare) de reguli de depanare care asigură calitatea înaltă a produsului software și reduc costul creării acestuia Formalizarea tehnologiei de depanare cu un control atent al procesului și al produsului creat ar trebui să contribuie la îmbunătățirea calității pachetelor software și la creșterea mai rapidă a calificărilor specialiștilor implicați în crearea acestora Autorul cărții adresează o parte din recomandări managerilor de proiect ai complexelor de programe de complexitate și scop diferite Aceste recomandări sunt în unele cazuri foarte simple ca formă, dar cu toate acestea pot îmbunătăți semnificativ nivelul de organizare a proiectării programelor Se știe că printre mulți specialiști - manageri ai dezvoltării complexelor software, se păstrează o abordare a creării acestora fără o bază metodologică profundă și o tehnologie reglementată ordonată a întregului proces Drept urmare, proiectele individuale sunt dezvoltate pe o perioadă lungă de timp, cu costuri mari de muncă, iar în unele cazuri programele sunt de o calitate insuficientă Suportul metodologic al designului modern al complexelor la un cost foarte mic poate afecta semnificativ productivitatea echipelor de programatori În același timp, principalele sunt dificultățile psihologice care apar odată cu introducerea metodelor de reglementare Pe de o parte, multor manageri li se pare că sunt foarte ușor de introdus și, prin urmare, reprezintă puțin mijloace eficiente, iar acest lucru nu trebuie făcut Pe de altă parte, programatorii cu înaltă calificare văd metodele ca o limitare a propriei inițiative creative și o încălcare a „artei” lor înalte, precum și experiența lor de lucru acumulată Drept urmare, ei încearcă să convingă managerii de inutilitatea reglementării metodologice a tehnologiei de proiectare a software-ului Din aceste poziții, cartea lui G Myers este utilă pentru liderii echipelor nu doar tinere, ci și experimentate Cartea propusă, datorită unei prezentări ordonate a principiilor programelor de depanare, va permite programatorilor calificați să-și sistematizeze cunoștințele și experiența Cartea este utilă în special pentru programatorii începători și studenți După cum sa menționat deja, atenția studenților este în mod tradițional concentrată pe limbajele de programare și instrumentele de traducere Cu toate acestea, acest lucru nu ia în considerare faptul că programarea în sine este o parte relativ mică a procesului de creare a complexelor software ( - %) Nu există cursuri de formare pentru depanarea, testarea, testarea și întreținerea programelor, precum și cursuri care reflectă întregul proces tehnologic de proiectare a acestora O serie de secțiuni ale cărții lui G Myers pot servi ca bază metodologică pentru prelegeri și exerciții practice despre depanarea programelor offline Cartea acoperă în profunzime problemele depanării offline a programelor și testarea lor deterministă, adică testarea în care fiecare combinație de date de intrare și rezultatele corespunzătoare ale execuției programului sunt cunoscute și controlate Dar depanarea modernă a complexelor software este mult mai largă în ceea ce privește conceptele și metodele sale Prin urmare, este recomandabil să ne oprim pe scurt asupra metodelor de testare stocastică și dinamică În complexele software complexe, este dificil, și adesea imposibil, să enumerați toate combinațiile de date inițiale și să verificați funcționarea programelor pe fiecare dintre ele În astfel de cazuri, se utilizează testarea stocastică, în care datele testului inițial sunt date de seturi de variabile aleatoare cu anumite distribuții, iar distribuțiile de variabile aleatoare sunt, de asemenea, folosite ca standarde pentru a compara rezultatele obținute nouă Criteriile de calitate a depanării devin stocastice și nu există o analiză a fiecărei implementări a testului Testarea stocastică realizează predominant funcții de control cu o variație mult mai mare a valorilor de test decât este disponibilă pentru testarea deterministă În acest caz, erorile individuale din programe pot să nu fie detectate dacă denaturează ușor valorile sau distribuțiile statistice medii În cazul în care se constată zone de modificare a valorilor de test care denaturează semnificativ distribuțiile statistice ale rezultatelor, trebuie să treceți la testarea deterministă pentru a diagnostica și localiza erorile în program În sistemele în timp real, este necesar să se verifice funcționarea complexelor software cu interacțiunea dinamică operațională a tuturor componentelor lor în procesul de prelucrare a diferitelor date inițiale Pentru aceasta se folosește testarea dinamică (depanare dinamică complexă), în cadrul căreia se verifică execuția programelor și prelucrarea datelor inițiale, ținând cont de momentul sosirii acestora, timpul de procesare, prioritatea, dinamica utilizării memoriei și interacțiunea cu alte programe Zona de variație a valorilor de test se extinde și mai mult (comparativ cu testarea stocastică) și, în consecință, devine mai dificil să se verifice corectitudinea implementării fiecărei valori de test Evaluările calității programului devin integrale și dinamice În cazul în care sunt detectate abateri ale rezultatelor execuției programului de la cele de referință presupuse, este necesar să se stabilească timpul de localizare a erorii și să se treacă la testarea statistică stocastică sau deterministă Ierarhia de testare și depanare prezentată este tipică pentru sistemele complexe de programe în timp real Testarea stocastică și dinamică necesită utilizarea instrumentelor de automatizare în pregătirea testelor și procesarea rezultatelor executării acestora În aceste cazuri, pregătirea manuală a testelor și verificarea manuală a acestora conform programului sunt practic inaplicabile Cu toate acestea, trebuie subliniată eficiența ridicată a inspecțiilor și a analizei manuale, așa cum este descrisă în detaliu de către autor rom, la etapele de depanare deterministă a modulelor și grupurilor de programe Depanarea dinamică necesită simulatoare automate de seturi de date de testare stocastice care se modifică în conformitate cu legile dinamice date Pentru a procesa rezultatele execuției programului și a compara cu valorile de referință, instrumentele de procesare automată sunt utilizate pe scară largă Ca urmare, mijloacele de asigurare a automatizării testării stocastice și dinamice pot fi mai complexe decât setul de programe testat Rentabilitatea instrumentelor de automatizare pentru testarea stocastică și dinamică depinde de scopul funcțional al pachetului software creat Deci, atunci când se elaborează programe de control în aviație și în spațiu, fără astfel de mijloace este imposibil să se obțină programe la nivelul de calitate cerut La traducerea cărții lui G Myers, au apărut o serie de dificultăți din cauza lipsei de terminologie stabilită în unele domenii ale proiectării programelor Pentru a evita traducerile literale sau transliterațiile nereușite ale termenilor tehnici semi-argotici englezi, traducătorii au încercat fie să folosească decât termeni deja aprobați, fie să dezvăluie esența conceptelor folosite Deci, în locul termenului „testare la stres” (testare la stres), aici este dat termenul „testare la sarcini limită” În mod similar, testarea complexă (testarea sistemului) este tradusă prin testarea sistemului etc Lista de referințe este completată de principalele lucrări ale specialiștilor sovietici și de cele mai importante publicații din ultimii ani În concluzie, trebuie subliniat încă o dată că arta testării software se transformă rapid în știința proiectării pachetelor software complexe care să satisfacă un anumit nivel de calitate În acest nou domeniu al științei aplicate se formează subiectul cercetării, metodelor de proiectare, tehnologiei și instrumentelor de automatizare pentru dezvoltarea unui produs software de înaltă calitate Există o clarificare a conceptelor și definițiilor de bază, se formează terminologia Testarea și depanarea capătă caracterul muncii colective pe o anumită tehnologie, care determină în mod semnificativ cantitatea și calitatea unui produs software Metode și mijloace de testare unsprezece Modificările trebuie luate în considerare împreună cu indicatorii de calitate ai programului care pot fi obținute cu o anumită cantitate de forță de muncă Sarcinile de analiză a eficienței depanării devin cele mai importante atunci când se creează complexe software complexe cu caracteristici de înaltă calitate Profesorul V V Lipaev CUVÂNT ÎNAINTE După cum știți, atunci când creați un proiect software tipic, aproximativ % din timpul total și mai mult de % din costul total sunt cheltuiți pentru verificarea (testarea) programului sau sistemului dezvoltat Pe baza acestui fapt, s-ar putea presupune că până acum testarea software-ului s-a ridicat la nivelul unei științe exacte Cu toate acestea, nu este De fapt, testarea software-ului este poate mai puțin acoperită decât orice alt aspect al dezvoltării software În plus, testarea a fost un subiect „demodat”, dacă ținem cont de publicațiile controversate pe această temă Cele de mai sus pot servi ca o justificare suficientă pentru scrierea cărții The Art of Software Testing De mai multe ori profesorii și lectorii mi-au spus: „Absolvenții noștri intră în industrie fără nicio idee practică despre cum să înceapă să testeze un program În plus, cursurile introductive existente nu oferă studenților niciun sfat cu privire la testarea și depanarea curriculum-ului lor ” Astfel, scopul acestei cărți este de a umple această lacună în cunoștințele programatorilor profesioniști și studenților la informatică După cum sugerează și titlul, cartea nu este o bază teoretică pentru testarea software-ului, ci mai degrabă un ghid practic care permite cititorului să stăpânească subiectul cu relativă ușurință Prin urmare, multe probleme legate de testarea programelor, cum ar fi demonstrarea matematică a corectitudinii lor, nu sunt discutate în mod intenționat aici Primul capitol oferă un scurt autotest pe care fiecare cititor trebuie să îl completeze înainte de a citi cartea Se pare că cele mai importante informații practice necesare pentru testarea software-ului sunt filozofice și economice principiile discutate în Cap În cap dezvoltă idei atât de importante, cum ar fi recenzii și verificări end-to-end ale testelor fără utilizarea unui computer Deși aici se pune accentul principal pe aspectele procedurale și manageriale ale acestor metode, ele sunt luate în considerare și din punctul de vedere al tehnicilor de găsire a erorilor Cititorul bine informat își imaginează că arta testării este direct proporțională cu capacitatea programatorului de a proiecta teste eficiente; acesta este subiectul cap În cap și, respectiv, , sunt date metode de testare a modulelor (sau subrutinelor) individuale și a combinațiilor acestora, iar în cap - câteva recomandări practice pentru programele de depanare Această carte este destinată celor trei grupuri principale de cititori Programatorii profesioniști, care formează primul grup, este puțin probabil să găsească aici multe informații noi, dar cu toate acestea își vor putea aprofunda cunoștințele în ceea ce privește metodele de testare Dacă cunoștințele dobândite permit cuiva să identifice încă o eroare în program, atunci valoarea cărții va crește de multe ori Al doilea grup de cititori sunt manageri de proiect de program Pentru ei, această carte oferă material practic nou pentru gestionarea procesului de testare A treia grupă include studenți specializați în programare și tehnologie informatică După citirea materialului din carte, aceștia vor putea înțelege problema testării software-ului și vor primi un set de metode eficiente Această carte poate fi oferită ca adaos la un curs de programare pentru a introduce studentul în subiectul testării software într-un timp scurt de învățare New York, iulie Glenford J Myers rjjIABA tECT PENTRU AUTOEVALUAREA Înainte de a începe lucrul la carte, recomandăm cititorului să efectueze următorul test simplu Sarcina este de a testa un program Acest program citește de pe un card perforat trei numere întregi, care sunt interpretate ca lungimile laturilor unui triunghi Programul imprimă apoi un mesaj care indică dacă triunghiul este echilateral, isoscel sau echilateral Scrieți pe o foaie de hârtie un set de teste (adică secvențe speciale de date) care credeți că vor testa în mod adecvat acest program După ce vă construiți testele, analizați-le Următorul pas este să evaluezi eficacitatea cecului tău Se pare că programul este mai greu de scris decât ar părea la început Au fost studiate diferite versiuni ale acestui program și a fost compilată o listă de erori comune Evaluează-ți suita de teste încercând să răspunzi la următoarele întrebări cu ajutorul acesteia Se acordă un punct pentru fiecare răspuns „da” Ați făcut un test care reprezintă un triunghi regulat neechilateral? (Rețineți că răspunsul „da” la testele cu valorile , , și , , nu este justificat, deoarece nu există triunghiuri cu astfel de laturi ) Ați făcut un test care să reprezinte un triunghi echilateral regulat? Ați făcut un test care să reprezinte un triunghi isoscel regulat? (Nu trebuie luate în considerare testele cu valorile , , ) Ați făcut cel puțin trei teste care reprezintă triunghiuri isoscele regulate obținute ca permutări a două laturi egale ale unui triunghi (de exemplu, , , ; , , și , , )? Ai făcut un test în care lungimea uneia dintre laturile triunghiului este zero? Ați făcut un test în care lungimea uneia dintre laturile triunghiului ia valoare negativă? Ați făcut un test care implică trei numere întregi pozitive, dintre care suma a două este egală cu al treilea? (Cu alte cuvinte, dacă programul a raportat că numerele , , reprezintă laturile unui triunghi inegal, atunci un astfel de program conține o eroare ) Ați făcut cel puțin trei teste cu valori date ale tuturor celor trei permutări, în care lungimea unei laturi este egală cu suma lungimilor celorlalte două laturi (de exemplu, , , ; , , și , , )? Ați făcut un test cu trei numere întregi pozitive, astfel încât suma a două dintre ele să fie mai mică decât al treilea număr (adică , , sau , , )? Ați finalizat cel puțin trei teste din categoria în care ați testat toate cele trei permutări (de exemplu, , , ; , , și , , )? Ați făcut un test în care toate laturile unui triunghi au lungime egală cu zero (adică , , )? Ați scris cel puțin un test care conține valori non-întregi? Ați făcut cel puțin un test care conține un număr greșit de valori (de exemplu, două, nu trei numere întregi)? Ați specificat în fiecare test nu numai valorile de intrare, ci și datele de ieșire ale programului? Desigur, nu există nicio garanție că o suită de teste care îndeplinește condițiile de mai sus va găsi toate erorile posibile Dar, deoarece întrebările - reprezintă erori care au apărut în diferite versiuni ale acestui program, un test adecvat pentru acesta ar trebui să le detecteze Dacă nu ești programator, atunci nu vei fi foarte bun la scrierea unui test Pentru comparație, observăm că programatorii profesioniști cu experiență obțin în medie doar - puncte din posibile Acest exercițiu ne arată că testarea chiar și a programelor banale ca acesta nu este o sarcină ușoară Și din moment ce acesta este cazul, luați în considerare dificultatea de a testa de programe de operator pentru un sistem de control al traficului aerian, un compilator sau un program de salarizare CAPITOLUL psihologia și economia testării software-ului Testarea ca obiect de studiu poate fi considerată din diverse puncte de vedere pur tehnic Cu toate acestea, cele mai importante întrebări în studiul testării sunt întrebările economice și psihologia dezvoltatorului Cu alte cuvinte, fiabilitatea testării unui program este determinată în primul rând de cine îl va testa și care este modul său de gândire și abia apoi de anumite aspecte tehnologice Prin urmare, înainte de a trece la problemele tehnice, ne vom concentra asupra acestor probleme Problemele de economie și psihologie sunt acoperite aici în doar câteva pagini Dar, după ce le-am înțeles, putem rezolva cu ușurință toate celelalte probleme de testare La prima vedere, întrebarea vitală a definirii termenului „testare” poate părea banală Necesitatea de a discuta despre acest termen se datorează faptului că majoritatea experților îl folosesc incorect, iar acest lucru duce, la rândul său, la teste proaste Astfel, de exemplu, sunt următoarele definiții: „Testarea este un proces care demonstrează absența unei erori, a unei laturi într-un program”, „Scopul testării este de a arăta că programul îndeplinește corect funcțiile prevăzute”, „Testarea” este un proces pentru a ne asigura că programul își îndeplinește scopul ” Aceste definiții descriu opusul a ceea ce se înțelege prin testare, deci sunt incorecte Lăsând definițiile deoparte, să presupunem că, dacă testăm un program, atunci trebuie să-i adăugăm un cost nou (adică testarea CDOIA nm eu Costă bani și este de dorit să recuperăm suma cheltuită prin creșterea costului programului) O creștere a costurilor înseamnă o creștere a calității sau o creștere a fiabilității programului Acesta din urmă este legat de detectarea și eliminarea erorilor din acesta * Prin urmare, programul nu este testat pentru a arăta că funcționează, ci mai degrabă opusul - testarea începe cu presupunerea că are erori (această presupunere este adevărată pentru aproape orice program) și apoi numărul maxim posibil este deja detectat Astfel, formulăm cea mai acceptabilă definiție: Testarea este procesul de executare a unui program pentru a detecta erori În timp ce toate raționamentele noastre pot părea un joc subtil de semantică, practica a arătat că acestea sunt cele care determină în mare măsură succesul testării Faptul este că alegerea corectă a scopului dă un efect psihologic important, deoarece orientarea scopului este caracteristică conștiinței umane Dacă ne stabilim scopul de a demonstra absența erorilor, atunci ne vom strădui în mod subconștient pentru acest scop, alegând date de testare pe care probabilitatea unei erori este mică În același timp, dacă sarcina noastră este să detectăm erori, atunci testul pe care îl creăm va avea o probabilitate mai mare de a detecta o eroare Această abordare va îmbunătăți semnificativ calitatea programului decât primul Această definiție a testării are mai multe implicații, care sunt discutate în diferite secțiuni ale cărții De exemplu, una dintre ele este că testarea este un proces distructiv (adică, opusul unuia creativ, constructiv) Aceasta explică de ce multora le este dificil Majoritatea oamenilor sunt înclinați către procesul constructiv de creare a obiectelor și, într-o măsură mai mică, spre procesul distructiv de destrămare De asemenea, din definiție rezultă cum să construiți un set de date de testare și cine ar trebui (și cine nu ar trebui) să testeze acest program Pentru a consolida definiția testării, să analizăm cele două concepte „de succes” și „eșuat” și, în special, utilizarea lor de către managerii de proiect la evaluarea rezultatelor testelor Majoritatea liderilor optsprezece Dezvoltatorii de proiecte numesc o rulare de testare un eșec dacă se găsește o eroare și, dimpotrivă, un succes dacă rulează fără erori Cel mai adesea, acesta este rezultatul unei înțelegeri eronate a termenului „testare”, deoarece, în esență, cuvântul „reușit” înseamnă „eficient”, iar cuvântul „nereușit” înseamnă „indezirabil”, „ineficient” Dar dacă testul nu a găsit o eroare, executarea lui este asociată cu o pierdere de timp și bani, iar termenul „reușit” nu i se poate aplica (Cititorul va înțelege că această afirmație este valabilă doar cu o discuție preliminară, deoarece nu putem ști înainte de execuție dacă testul va duce la detectarea unei erori sau nu Cu toate acestea, această problemă este luată în considerare mai târziu ) Execuția de testare care a condus la descoperirea erorii nu poate fi numită un eșec, fie și doar pentru că, după cum sa menționat mai sus, aceasta este o investiție utilă De aici rezultă că cuvintelor „reușit” și „nereușit” trebuie să li se acorde un sens opus celui general acceptat Prin urmare, în viitor, vom numi o rulare de test cu succes dacă este detectată o eroare în timpul execuției sale și nereușită dacă se obține un rezultat corect Să facem o analogie cu vizita la un medic bolnav Dacă testul de laborator recomandat de medic nu dezvăluie cauza bolii, atunci nu vom numi un astfel de studiu reușit - nu este reușit: la urma urmei, factura pacientului a scăzut cu patruzeci de dolari și este încă bolnav Dacă studiul a arătat că pacientul are un ulcer de stomac, atunci este de succes, deoarece medicul poate prescrie cursul necesar de tratament Prin urmare, medicii folosesc acești termeni în sensul de care avem nevoie (Analogia aici, desigur, este că programul care trebuie testat este ca un pacient bolnav ) Definiții precum „testarea este procesul de demonstrare a absenței bug-urilor” dau naștere unei alte probleme: stabilesc un scop care nu poate fi atins de niciun program, chiar și unul foarte banal (Dacă nu puteți fi de acord cu această afirmație, atunci luați-o deocamdată - va fi discutată mai jos ) Rezultatele cercetării psihologice arată că, dacă o sarcină imposibilă este pusă înaintea unei persoane, atunci ea funcționează mai rău De exemplu, es nouăsprezece dacă ceri cuiva să rezolve un puzzle de cuvinte încrucișate în numărul de duminică al New York Times în minute, atunci după minute nu va avea un succes semnificativ; este clar că aceasta este o sarcină imposibilă Dacă decizia este dată de patru ore, atunci după minute rezultatul va fi mai bun Cu alte cuvinte, definirea testării ca proces de detectare a erorilor îl transpune în categoria problemelor rezolvabile și depășește astfel dificultatea psihologică O altă problemă apare atunci când se folosește următoarea definiție pentru testare: „Testarea este procesul prin care se asigură că un program își îndeplinește scopul”, deoarece un program care îndeplinește această definiție poate conține erori Dacă programul nu face ceea ce i se cere, atunci este clar că conține erori Totuși, pot apărea greșeli și atunci când face ceea ce nu i se cere Luați în considerare problema triunghiului din cap Un program care definește corect triunghiuri non-isoscele, isoscele și echilaterale va face totuși o eroare dacă face ceva ce nu ar trebui să facă (de exemplu, raportați că triplul , , reprezintă un triunghi neechilateral și triplul , , - echilateral) Erori din această clasă pot fi detectate mai rapid dacă testarea este privită ca un proces de găsire a erorilor, mai degrabă decât ca demonstrarea corectitudinii lucrării În rezumat, testarea este văzută ca un proces distructiv de încercare de a găsi erori într-un program (care se presupune că sunt) Un set de teste care contribuie la detectarea unei erori este considerat reușit Desigur, toată lumea vrea în cele din urmă să câștige un anumit grad de încredere testând că programul lor face ceea ce este intenționat să facă și nu face ceea ce nu a fost conceput pentru a face, dar cea mai bună modalitate de a atinge acest obiectiv este să găsești erori direct Să presupunem că cineva vine la tine cu afirmația: „Programul meu este grozav” (adică, nu conține erori) Cel mai bun mod de a dovedi validitatea unei astfel de afirmații este să încerci să o infirmi, să găsești inexactități, mai degrabă decât să fii de acord pur și simplu că programul funcționează corect pe un anumit set de date de intrare ^ECONOMIA TESTĂRII Având în vedere această definiție a testării, următorul pas este luarea în considerare a posibilității de a crea un test care detectează toate erorile de program Să arătăm că răspunsul este negativ chiar și pentru cele mai banale programe În general, este imposibil să detectați toate erorile de program Și aceasta, la rândul său, dă naștere la probleme economice, sarcini legate de funcțiile umane în procesul de depanare, metode de construire a testelor Testarea programului ca o cutie neagră O modalitate de a studia întrebarea pusă este de a studia o strategie de testare numită strategie cutie neagră, testare bazată pe date sau testare bazată pe input-output Când utilizați această strategie, programul este tratat ca o cutie neagră Cu alte cuvinte, o astfel de testare are ca scop aflarea circumstanțelor în care comportamentul programului nu corespunde specificației sale Datele de testare sunt utilizate numai în conformitate cu specificațiile programului (adică, fără a lua în considerare cunoștințele despre structura sa internă) Cu această abordare, detectarea tuturor erorilor din program este un criteriu pentru testarea exhaustivă a intrărilor Acesta din urmă poate fi realizat dacă toate seturile posibile de date de intrare sunt utilizate ca seturi de testare Necesitatea alegerii acestui criteriu este ilustrată de exemplul următor Dacă în aceeași problemă a triunghiului un triunghi este identificat corect ca fiind echilateral, nu există nicio garanție că toate celelalte triunghiuri echilaterale vor fi de asemenea identificate corect Deci, pentru un triunghi cu laturile , , , se poate asigura o verificare specială și este considerat neechilateral Deoarece programul este o cutie neagră, singura modalitate de a satisface criteriile de mai sus este să încercați toate valorile de intrare posibile Astfel, un test exhaustiv pentru problema triunghiului trebuie să includă triunghiuri echilaterale cu lungimea laturilor până la maxim număr întreg Acesta este, desigur, un număr astronomic, dar nu asigură caracterul complet al verificării Este probabil ca unele erori să rămână, de exemplu, programul poate reprezenta un triunghi cu laturile , , nu este echilateral, iar cu laturile , D, este echilateral Pentru a detecta astfel de erori, este necesar să se enumere nu numai toate seturile de intrare rezonabile, ci și toate posibilele Prin urmare, concluzionăm că un test exhaustiv al problemei triunghiului necesită un număr infinit de teste Dacă un astfel de test pare dificil, atunci este și mai dificil să creezi un test exhaustiv pentru un program mare Figurat vorbind, numărul de teste poate fi estimat ca „un număr mai mare decât infinitul” Să presupunem că se încearcă testarea în cutie neagră a unui compilator cu Cobol Pentru a construi un test exhaustiv, trebuie să utilizați întregul set de programe Cobol corecte (infinit de fapt) și întregul set de programe incorecte (adică, într-adevăr, un număr infinit) pentru a vă asigura că compilatorul detectează toate erorile Numai în acest caz nu va fi compilat un program incorect din punct de vedere sintactic Dacă programul are propria memorie (de exemplu, un sistem de operare, o bază de date sau un sistem de rezervare a biletelor), atunci situația este și mai gravă În astfel de programe, execuția unei comenzi (de exemplu, un job, o interogare de bază de date, o copie de rezervă) depinde de ce evenimente au precedat-o, adică de comenzile anterioare Aici este necesar să enumerați nu numai toate comenzile posibile, ci și toate secvențele posibile ale acestora Din cele de mai sus rezultă că construirea unui test de intrare exhaustiv este imposibilă Acest lucru este susținut de două argumente: în primul rând, nu puteți crea un test care să garanteze absența erorilor; în al doilea rând, dezvoltarea unor astfel de teste este contrară cerințelor economice Deoarece testarea exhaustivă este exclusă, scopul nostru ar trebui să fie maximizarea rentabilității investiției în testare (cu alte cuvinte, maximizarea numărului de erori găsite de un singur test) Pentru a face acest lucru, putem lua în considerare structura internă a programului și putem face unele rezonabile, dar bineînțeles nu pe deplin garantate fiabilitatea ipotezei (de exemplu, este rezonabil să presupunem că, dacă programul a considerat triunghiul , , ca fiind echilateral, atunci triunghiul cu laturile , , va fi și el același) Această problemă este discutată în cap la studierea strategiei de construcție a testului Testarea programului ca o cutie albă Strategia cutiei albe, sau strategia de testare bazată pe logică, vă permite să explorați structura internă a unui program În acest caz, testerul primește date de testare analizând logica programului (din păcate, specificația programului nu este adesea folosită aici) Să comparăm metoda de construire a testelor pentru această strategie cu testarea exhaustivă a strategiei cutiei negre Pentru cei neinițiați, poate părea că este suficient să construiți o suită de teste în care fiecare instrucțiune să fie executată cel puțin o dată; este ușor să arăți că acest lucru este fals Fără a intra în detalii (deoarece acestea sunt discutate în Capitolul ), subliniem doar că testarea exhaustivă de intrare poate fi asociată cu testarea exhaustivă a rutelor Se presupune că programul este pe deplin verificat dacă, cu ajutorul testelor, este posibil să se efectueze execuția acestui program de-a lungul tuturor rutelor posibile ale fluxului său (grafic) de transferuri de control Ultima afirmație are două puncte slabe Una dintre ele este că numărul de trasee care nu se repetă în program este astronomic Pentru a verifica acest lucru, luați în considerare cel prezentat în Fig grafic de transfer de control al celui mai simplu program Fiecare vârf, sau cerc, denotă o secțiune a programului care conține o secvență de instrucțiuni liniare, care se poate termina cu o instrucțiune de ramură Arcurile care se termină cu săgeți corespund transferurilor de control Aparent, graficul descrie un program de - de instrucțiuni, inclusiv o buclă DO care este executată de cel puțin de ori Există mai multe instrucțiuni IF în interiorul buclei Pentru a determina numărul de rute care nu se repetă în timpul execuției programului, numărăm numărul de rute care nu se repetă de la punctul A la B, presupunând că toate comenzile sunt independente reciproc Acest număr este calculat ca suma de + + + = IO , sau de trilioane, unde este numărul de căi din interiorul buclei Deoarece acest număr este dificil de estimat pentru majoritatea cititorilor, iată un exemplu: dacă presupunem că petrecem cinci minute pentru compilarea fiecărui test, atunci ne-ar lua aproximativ un miliard de ani pentru a construi un set de teste o singura data Orez Graficul transmisiei de control al unui program mic Desigur, în programele reale, salturile condiționate nu pot fi independente reciproc, adică numărul de rute de execuție va fi ceva mai mic Pe de altă parte, programele reale sunt mult mai mari decât programul simplu prezentat în Fig Prin urmare, testarea exhaustivă a rutelor, precum testarea exhaustivă de intrare, este nu numai imposibilă, ci și imposibilă Al doilea punct slab al afirmației este că, deși testarea exhaustivă a rutelor este un test complet și, deși fiecare rută dintr-un program poate fi testată, programul în sine va conține erori Acest lucru este explicat după cum urmează În primul rând, testarea exhaustivă a rutelor nu poate garanta că programul corespunde descrierii De exemplu, în loc de programul de sortare ascendent necesar, următorul program a fost scris accidental: sortarea gramelor în ordine descrescătoare În acest caz, valoarea rutelor de testare nu este mare, deoarece după testare programul va avea o singură eroare, adică programul este incorect În al doilea rând, programul poate fi incorect din cauza faptului că unele rute sunt omise Testarea exhaustivă a rutelor nu va dezvălui absența acestora În al treilea rând, testarea exhaustivă a rutelor nu poate detecta erori care depind de datele procesate Există multe exemple de astfel de erori Să luăm una dintre ele Să presupunem că un program trebuie să compare două numere pentru convergență, adică să determine dacă diferența dintre două numere este mai mică decât un număr predeterminat Expresia poate fi scrisă DACĂ ((A -B) X| Y este nevalid; ar trebui scris ca (I>X)|(I>Y) Când comparăm trei numere pentru egalitate, expresia IF(A = = B = C) înseamnă ceva complet diferit Dacă este necesară verificarea relației matematice X>Y>Z, expresia (X>Y)&(Y>Z) va fi corectă Compară programul mantisele sau numerele în virgulă mobilă care sunt reprezentate în mașină în formă binară? Aceasta este uneori o sursă de erori din cauza trunchierii cifrelor cel mai puțin semnificative și din cauza egalității inexacte a numerelor în reprezentări binare și zecimale Sunt corecte ipotezele despre ordinea evaluării și succesiunea operatorilor pentru expresiile care conțin mai mult de un operator boolean? Cu alte cuvinte, dacă expresia (A = )&(B = ) | (C = ), este clar care dintre operații se efectuează prima: ȘI sau SAU? Modul în care un anumit compilator execută expresii booleene afectează rezultatul execuției programului? De exemplu, operatorul DACĂ (X=#= ) și ((Y/X)>Z) este acceptabilă pe unele compilatoare PL/ (adică, compilatoare care nu mai verifică de îndată ce una dintre expresiile din funcția AND este evaluată ca falsă), dar va avea ca rezultat o împărțire cu pe alte compilatoare Erori în transferul controlului Dacă programul conține un comutator (de exemplu, instrucțiunea GO TO calculată în Fortran), poate valoarea indexului să depășească vreodată numărul de salturi posibile? De exemplu, voi lua întotdeauna valoarea , sau în operatorul Fortran GO TO ( , , ), /? Va fi în cele din urmă finalizat fiecare ciclu? Veniți cu o dovadă informală sau cu argumente care să susțină finalizarea lor Programul, modulul sau subprogramul va fi în cele din urmă finalizat? Este posibil ca din cauza condițiilor prealabile, bucla să nu poată fi executată niciodată? Dacă da, este aceasta o neglijență? De exemplu, ce se întâmplă cu buclele care încep cu instrucțiuni FACEȚI CÂND (NEGĂSIT) DO I = X LA Z dacă valoarea inițială a lui NOTFOUND este falsă sau dacă X este mai mare decât Z? Pentru buclele controlate atât de numărul de iterații, cât și de o condiție booleană (de exemplu, o buclă pentru a organiza o căutare), care este secvența „scufundare în corpul buclei”? De exemplu, ce se întâmplă cu o buclă cu titlu FACEȚI = APOI MĂRIMĂ TABUL CÂND (NEGĂSIT) dacă NOTFOUND nu evaluează niciodată ca fals? Există erori „excepționale” (de exemplu, prea multe sau prea puține iterații)? Dacă limbajul de programare conține conceptul grupuri de declarații (de exemplu, DO sunt grupuri din PL/ limitate de instrucțiuni DO, END), există o declarație END explicită pentru fiecare grup și instrucțiunile END corespund grupurilor lor? Există soluții implicite? De exemplu, să presupunem că un parametru de intrare este de așteptat să fie , sau Este atunci logic să presupunem că ar trebui să fie dacă nu este sau ? Dacă este așa, presupunerea este corectă? Erori de interfață Este numărul de parametri primiți de modulul în cauză egal cu numărul de argumente transmise de fiecare dintre modulele apelante? Este corectă comanda lor? Atributele (cum ar fi tipul și dimensiunea) fiecărui parametru se potrivesc cu atributele argumentului său corespunzător? Unitățile fiecărui parametru se potrivesc cu unitățile argumentelor corespunzătoare? De exemplu, există cazuri în care valoarea parametrului este în grade și argumentul este în radiani? Numărul de argumente transmise de la modulul în cauză către alt modul este egal cu numărul de parametri așteptați în modulul apelat? Atributele fiecărui argument transmis altui modul se potrivesc cu atributele parametrului corespunzător din modulul în cauză? Unitățile fiecărui argument transmis altui modul se potrivesc cu unitățile parametrului corespunzător din modulul în cauză? Dacă sunt apelate funcții încorporate, numărul, atributele și ordinea argumentelor sunt corecte? Dacă un modul are mai multe puncte de intrare, parametrul este întotdeauna trecut indiferent de punctul de intrare? O astfel de eroare apare în a doua instrucțiune de atribuire a următorului program PL/ : A: PROCEDURĂ (W, X); W=X+ ; ÎNTOARCERE; B: INTRARE(Y,Z); Y=X+Z; SFÂRŞIT; Modificarea subrutinei este un parametru care ar trebui folosit doar ca valoare de intrare? Dacă există variabile globale (de exemplu, variabile în PL/ cu atributul EXTERN, variabile specificate în instrucțiunile Fortran COMMON), au aceleași definiții și atribute în toate modulele care le accesează? Sunt constantele transmise ca argumente? În unele implementări ale Fortran, declarații precum Apelați SUBX (J, ) sunt periculoase deoarece dacă subrutina SUBX atribuie o valoare celui de-al doilea parametru, valoarea constantei va fi modificată Erori I/O Sunt corecte atributele fișierelor declarate explicit? Sunt corecte atributele declarației OPEN? Specificațiile de format sunt de acord cu informațiile din instrucțiunile I/O? De exemplu, fiecare instrucțiune FORMAT se potrivește (în ceea ce privește numărul de date elementare și atributele acestora) cu instrucțiunile corespunzătoare READ și WRITE dintr-un program Fortran? Același lucru este valabil și pentru verificarea corespondenței dintre o listă de date și o listă de formate în instrucțiunile PL/ I/O Dimensiunea înregistrării este egală cu dimensiunea zonei de memorie pentru I/O? Toate fișierele sunt deschise înainte de a le folosi? Sunt semnele de sfârșit de dosar detectate și interpretate corect? Sunt stările de eroare I/O tratate corect? Există erori semantice sau gramaticale în textul afișat de program în imprimare sau pe ecran? Alte tipuri de control Dacă compilatorul produce un tabel de referințe încrucișate ale identificatorilor, verificați valorile care nu sunt menționate în această listă sau există o singură referință Dacă compilatorul produce o listă de atribute, verificați atributele fiecărei valori pentru a vă asigura că Garantați că nu există atribute neașteptate sau lipsă în program Dacă programul este compilat cu succes, dar compilatorul emite unul sau mai multe mesaje de „avertismente” sau „informații”, verificați cu atenție fiecare dintre ele Avertismentul indică faptul că compilatorul este „suspect” cu privire la corectitudinea acțiunilor dvs Toate aceste „suspiciuni” trebuie luate în considerare Mesajele informaționale pot enumera variabile nedeclarate sau constructe de limbaj care împiedică optimizarea codului Este programul (sau modulul) suficient de stabil? Cu alte cuvinte, își validează datele de intrare? Lipsește vreo funcție din program? O listă sumar de întrebări pentru identificarea erorilor este prezentată în fig și MANIPULAREA DATELOR Sunt utilizate variabile cu valori nesetate? Indicii se află în afara limitelor date? Există indici non-întregi? Există contestații „atârnate”? Sunt atributele corecte pentru toate aliasurile? Se potrivesc atributele înregistrării și structurii? Sunt adresele șirurilor de biți calculabile? Sunt șirurile de biți transmise ca argumente? Sunt corecte atributele memoriei bazate? Definițiile structurii care îi sunt date în diverse proceduri corespund între ele? Sunt depășite limitele liniei? Există și alte erori în operațiunile de indexare sau la accesarea tablourilor după index? TEHNICA DE CALCUL Se calculează variabilele nearitmetice? Se fac calcule folosind diferite tipuri de date? Există calcule pentru variabile de lungimi diferite? Este lungimea rezultatului mai mică decât lungimea valorii calculate? Este posibil să se reverse sau să se piardă un rezultat intermediar în timpul calculului? Există împărțire la zero? Există inexactități atunci când lucrați cu numere binare? Valoarea variabilei este în afara intervalului setat? Este clară ordinea operatorilor? Este corectă împărțirea numerelor întregi? DESCRIEREA DATELOR Sunt descrise toate variabilele? Este clară absența atributelor? Sunt matricele și șirurile inițializate corect? Dimensiunea, tipul și clasa de stocare sunt definite corect? Este inițializarea în concordanță cu clasa de stocare? Se poate face fără variabile cu nume similare? COMPARAŢIE Se compară valorile tipurilor incompatibile? Sunt comparate cantități de diferite tipuri? Relațiile de comparație sunt corecte? Sunt corecte expresiile booleene? Se combină comparațiile și expresiile booleene? Se compară mărimile fracționale în formă binară? Este clară ordinea operatorilor? Este clară procedura de analizare a expresiilor booleene de către compilator? pentru a detecta erori în inspecții Orez Lista consolidată de întrebări (partea ) TRANSFERUL CONTROLULUI Valoarea indexului dintr-un buton radio poate depăși numărul de tranziții? Va fi finalizat fiecare ciclu? Va fi finalizat programul? Există vreo buclă care eșuează din cauza condițiilor prealabile? Sunt corecte posibilele scufundări în ciclu? Există erori în abaterea numărului de iterații de la normă? Se potrivesc declarațiile DO și END? Există soluții implicite? INTERFATA Este numărul de parametri de intrare egal cu numărul de argumente? Se potrivesc atributele parametrilor și ale argumentelor? INTRARE IEȘIRE Sunt corecte atributele fișierului? Sunt corecte afirmațiile DESCHISE? Formatul specificației se potrivește cu instrucțiunile I/O? Dimensiunea tamponului se potrivește cu dimensiunea înregistrării? Fișierele sunt deschise înainte de a le folosi? Sunt detectate semnele de sfârșit de fișier? Sunt detectate erori I/O? Există erori de text în rezultat? ALTE CONTROALE Există variabile în tabelul de referințe încrucișate care nu sunt referite? INTERFATA ALTE CONTROALE Unitățile de parametri și argumente se potrivesc? Numărul de argumente transmise modulelor apelate este egal cu numărul de parametri? Atributele argumentelor transmise modulelor apelate se potrivesc cu atributele parametrilor? Unitățile argumentelor transmise modulelor apelate se potrivesc cu unitățile parametrilor? Numărul, atributele și ordinea argumentelor sunt corecte pentru funcțiile încorporate? Există acces la parametri care nu au legătură cu punctul de intrare curent? Subrutina modifică argumentele care sunt doar intrări? Sunt definițiile variabilelor globale consecvente în toate modulele care le folosesc? Sunt constantele transmise ca argumente? Lista de atribute este conform așteptărilor? Există avertismente sau mesaje informative? Se efectuează controlul corectitudinii datelor de intrare? Lipsesc caracteristici? Orez Lista consolidată de întrebări pentru identificarea erorilor de inspecție (partea ) VIZIONARI ÎN CRUCE Revizuirea end-to-end, ca și inspecția, este un set de proceduri și metode de detectare a erorilor, efectuate de un grup de persoane care examinează textul programului O astfel de revizuire are multe în comun cu procesul de inspecție, dar procedurile lor sunt oarecum diferite și, în plus, aici sunt folosite și alte metode de detectare a erorilor Asemenea unei inspecții, o examinare este efectuată ca o sesiune continuă care durează una sau două ore See Through Team ' este format din - persoane Este format dintr-un președinte, ale cărui funcții sunt similare cu cele ale unui președinte dintr-un grup de inspecție, un secretar care notează toate erorile constatate și un specialist în teste Opiniile diferă cu privire la cine ar trebui să fie al patrulea și al cincilea membru al grupului Desigur, unul dintre ei trebuie să fie programator În ceea ce privește al cincilea participant, există următoarele ipoteze: ) un programator înalt calificat; ) un expert în limbaj de programare; ) un începător (al cărui punct de vedere nu este influențat de experiența anterioară); ) persoana care în cele din urmă va opera programul; ) un participant la un alt proiect; ) cineva din același grup de programatori ca și autorul programului Procedura inițială pentru o prezentare este aceeași ca și pentru o inspecție: materialele sunt distribuite participanților în avans, cu câteva zile înainte de întâlnire, permițându-le să se familiarizeze cu programul Cu toate acestea, procedura ședinței este diferită de procedura ședinței de inspecție În loc să citească pur și simplu textul programului sau să folosească o listă de erori, participanții la întâlnire „acţionează ca un computer” Testerul desemnat prezintă audienței un număr mic de teste scrise care reprezintă seturi de intrări (și ieșiri așteptate) pentru un program sau modul În timpul întâlnirii, fiecare test este efectuat mental Aceasta înseamnă că datele de testare sunt procesate conform logicii programului Starea programului (adică, valorile variabilelor) este urmărită pe hârtie sau pe tablă Desigur, numărul de teste ar trebui să fie mic și ar trebui să fie de natură simplă, deoarece viteza de execuție a programului uman este cu multe ordine de mărime mai mică decât cea a unei mașini Prin urmare, testele în sine nu joacă un rol critic, ci mai degrabă servesc ca mijloc pentru înțelegerea inițială a programului și ca bază pentru a întreba programatorul despre logica de proiectare și ipotezele făcute În majoritatea recenziilor end-to-end, atunci când rulează testele în sine, ei găsesc mai puține erori decât atunci când intervievează un programator Ca și în cazul unei inspecții, opinia participanților este factorul decisiv Comentariile ar trebui abordate la program, nu la programator Cu alte cuvinte, greșelile nu sunt văzute ca o slăbiciune a persoanei care le-a făcut Ele mărturisesc complexitatea procesului de creare a programelor și sunt rezultatul naturii încă primitive a metodelor de programare existente Trecerile ar trebui să se desfășoare în același mod ca procesul de inspecție descris mai devreme Efectele secundare care apar în timpul acestui proces (identificarea părților predispuse la erori ale programului și învățarea din analiza erorilor, stilul și metodele) sunt, de asemenea, caracteristice procesului de parcurgere VERIFICAREA LA MASĂ A treia metodă de detectare manuală a erorilor este „verificarea la masă” folosită mai devreme decât alte metode Verificările din tabel pot fi considerate ca verificări ale codului sursă sau proceduri detaliate efectuate de o singură persoană care citește codul programului, îl verifică cu o listă de erori și/sau rulează date de testare prin program În cea mai mare parte, verificarea la masă este relativ neproductivă Acest lucru se datorează în primul rând faptului că o astfel de verificare este un proces complet dezordonat Al doilea motiv, mai important, este că testarea pe tabel este opusă unuia dintre principiile de testare din Cap , conform căruia programatorul își testează de obicei propriile programe în mod ineficient Prin urmare, verificarea tabelului poate fi făcută cel mai bine de către o altă persoană decât autorul programului (de exemplu, doi programatori pot schimba programe în loc să își verifice propriile programe la masă), dar chiar și atunci o astfel de verificare este mai puțin eficientă decât trecerea sau inspecții Acest motiv este motivul principal pentru formarea unui grup în timpul revizuirilor sau inspecțiilor end-to-end ale textului sursă Întâlnirea grupului este favorabilă creării unei atmosfere de competiție sănătoasă: participanții doresc să-și arate cea mai bună parte în găsirea erorilor Când verificați la masă, acest efect valoros, desigur, lipsește Pe scurt vorbind Cu alte cuvinte, verificarea tabelului este cu siguranță utilă, dar este mult mai puțin eficientă decât inspecția sau trecerea codului sursă EVALUARE PRIN VIZIONARE Ultimul proces manual de revizuire a programului nu este despre testarea programului (adică scopul său nu este de a găsi erori) Cu toate acestea, acest proces este descris aici deoarece este legat de ideea de a citi un text Evaluarea revizuirii [ ] este o metodă de evaluare a unui program anonim în ceea ce privește calitatea generală, mentenabilitatea, extensibilitatea, mentenabilitatea și claritatea acestuia Scopul acestei metode este de a oferi programatorului un mijloc de autoevaluare Un programator este selectat pentru a acționa ca administrator de proces Administratorul, la rândul său, selectează aproximativ - de participanți ( este numărul minim pentru păstrarea anonimatului) Se așteaptă ca membrii să fie de același profil (de exemplu, programatorii COBOL și programatorii sistemului Assembler nu trebuie grupați împreună) Fiecare participant este rugat să trimită spre considerare două dintre programele sale: cel mai bun (din punctul său de vedere) și de proastă calitate Programele selectate sunt distribuite aleatoriu între participanți Li se oferă patru programe pentru a fi luate în considerare Două dintre ele sunt „cele mai bune” și două sunt „cele mai proaste”, dar recenzentului nu i se spune ce program aparține cărui grup Fiecare participant petrece de minute urmărind un program și completează un chestionar pentru a-l evalua După vizualizarea tuturor celor patru programe, calitatea lor relativă este evaluată Chestionarul de evaluare cere evaluatorului să evalueze programul pe o scară de șapte puncte ( pentru un „da sigur”, pentru un „nu” definit), ca răspuns la, de exemplu, următoarele întrebări: A fost programul ușor de înțeles? Au fost rezultatele proiectului la nivel înalt clare și acceptabile? Au fost rezultatele proiectului de nivel scăzut clare și acceptabile? Vă este ușor să modificați acest program? Ați simți satisfacția de a scrie un astfel de program? De asemenea, evaluatorului i se cere să furnizeze comentarii generale și recomandări pentru îmbunătățirea programului După vizionare, fiecărui participant i se oferă un chestionar anonim cu o evaluare a celor două programe ale sale Participanții primesc un rezumat statistic care conține o clasificare generală și detaliată a propriilor programe în comparație cu setul complet de programe și o analiză a modului în care evaluările altor programe se potrivesc cu evaluările acelorași programe oferite de alți evaluatori Scopul unei astfel de revizuiri este de a permite programatorilor să-și evalueze propriile calificări Această metodă pare să fie utilă atât pentru aplicații industriale, cât și pentru educație LITERATURĂ Weinberg G M Psihologia programării computerelor New York, Van Nostrand Reinhold, M ers GJ Software Reliability: Principii și practici New York, Wiley-Interscience, Traducere rusă: Myers G Software Reliability M , Mir, Myers GJ Compozit/Design structurat New York, Van Nostrand Reinhold, M ers GJ Un experiment controlat în testarea programelor și instrucțiunile/inspecțiile codului —Comun ACM, , ( ), p - Perriens MP O aplicare a inspecțiilor formale pentru dezvoltarea programelor structurate de sus în jos — RADC—TR— — , IBM Federal System Div , Gaithersburg, Md , (NTIS AD/A— ) Afișați tipurile ML, B o s ku MI, timpii de distribuție și de testare și corecție pentru erori de programare — Proceedings of the International Conference on Reliable Software New York, IEEE, , p - F agan ME Design și inspecții de cod pentru a reduce erorile în dezvoltarea programului — IBM Systems J , , ( ), p - Freeman R D Un experiment în dezvoltarea software-ului — The Beli System Technical Journal, Special Safeguard Supplement, , p SI -S A s c o în J et al Specificație de inspecție cod — TR- , IBM System Communication Division, Kingston, NY, Anderson N și Shneiderman B Utilizarea evaluărilor de la egal la egal în evaluarea calității programelor de calculator - IFSM-TR- , Universitatea din Maryland, CAPITOLUL PROIECTARE DE TESTARE Rezultatele cercetărilor psihologice discutate în Cap arată că cel mai mare accent în testarea software-ului este pe proiectarea sau crearea de teste eficiente Acest lucru se datorează imposibilității testării „complete” a programului, adică un test pentru orice program va fi neapărat incomplet (cu alte cuvinte, testarea nu poate garanta absența tuturor erorilor) Strategia de proiectare este de a încerca să reduceți pe cât posibil această „incompletitudine” Dacă introduceți restricții privind timpul, costul, timpul mașinii etc , atunci următoarea devine întrebarea cheie a testării: Care dintre toate testele posibile are cea mai mare probabilitate de a găsi cele mai multe erori? Un studiu al metodologiilor de proiectare a testelor oferă un răspuns la această întrebare Poate cea mai proastă dintre toate metodologiile este testarea cu intrări aleatorii (stochastice) - procesul de testare a unui program prin selectarea aleatorie a unui subset al tuturor intrărilor posibile În ceea ce privește probabilitatea de a găsi majoritatea erorilor, un set de test selectat aleatoriu are o probabilitate scăzută de a fi un subset optim sau aproape optim Acest capitol discută mai multe abordări care vă permit să alegeți mai inteligent datele de testare În cap , s-a arătat că testarea exhaustivă a cutiei negre sau a cutiei albe nu este în general posibilă Cu toate acestea, sa observat că o strategie de testare acceptabilă poate avea elemente ale ambelor abordări Un astfel de jav Aceasta este strategia prezentată în acest capitol Este posibil să se dezvolte un test destul de complet utilizând o anumită metodologie de proiectare cu cutie neagră și apoi să o completeze cu un test al logicii programului (adică, folosind metode cu caseta albă) Metodologiile discutate în acest capitol sunt prezentate mai jos Cutie neagră Diviziunea echivalentă Analiza valorilor la limită Aplicarea diagramelor funcționale Eroare de ghicire cutie alba Acoperire operator Acoperirea soluției Acoperirea stării Acoperire de decizie/condiție Acoperirea combinatorie a condițiilor Deși metodele enumerate vor fi luate în considerare separat aici, atunci când se proiectează un test de program eficient, se recomandă utilizarea dacă nu toate aceste metode, atunci cel puțin majoritatea, deoarece fiecare metodă are anumite avantaje și dezavantaje (de exemplu, capacitatea pentru a detecta și a sări peste diferite tipuri de erori) Adevărat, aceste metode sunt foarte laborioase, așa că unii experți, familiarizandu-se cu ele, ar putea să nu fie de acord cu această recomandare Cu toate acestea, trebuie înțeles că testarea unui program este o sarcină extrem de dificilă Pentru a ilustra acest lucru, să citam o zicală binecunoscută: „Dacă crezi că dezvoltarea și codarea unui program este un lucru dificil, atunci nu ai văzut încă nimic” Procedura recomandată este de a dezvolta teste folosind metode cutie neagră și apoi, ca o condiție prealabilă, teste suplimentare folosind metode cutie albă Metodele de cutie albă mai utilizate pe scară largă sunt discutate mai întâi TESTARE PRIN ACOPERIRE LOGICA PROGRAMULUI Testarea cutie albă este caracterizată prin măsura în care testele execută sau acoperă logica (codul sursă) a unui program Așa cum se arată în cap , testarea exhaustivă a casetei albe implică executarea fiecărei căi din software pe mine; dar din moment ce într-un program cu bucle de obicei nu este posibilă efectuarea fiecărei căi, testare toate căile nu sunt considerate în această carte ca fiind una orientată spre viitor Dacă refuzăm complet să testăm toate căile, atunci putem arăta că criteriul de acoperire este execuția fiecărei instrucțiuni a programului cel puțin o dată Din păcate, acesta este un criteriu slab, deoarece executarea fiecărei instrucțiuni cel puțin o dată este o condiție necesară, dar nu suficientă pentru testarea cutie albă acceptabilă (Figura ) Să presupunem că în fig prezintă un mic program care ar trebui să fie Orez Un mic program de testat testat Programul echivalent scris în PL/ este: LA: PROCEDURA (A, B, X); DACA ((A > ) & (B= )) ATUNCI FACETI; X = X/A; SFÂRŞIT; DACA ((A= ) I (X> )) ATUNCI FACETI; X = X+ ; SFÂRŞIT; SFÂRŞIT; Este posibil să se execute fiecare instrucțiune prin scrierea unui singur test care ar implementa calea as Cu alte cuvinte, dacă punctul a ar fi setat la A = , B = și X = , fiecare instrucțiune ar fi executată o dată (de fapt, X poate lua orice valoare) Din păcate, acest criteriu este mai rău decât pare prima vedere De exemplu, să fie scrisă prima soluție ca sau, nu ca și La testarea conform acestui criteriu, această eroare nu va fi detectată Fie ca a doua soluție să fie scrisă în program ca X> ; nici această eroare nu va fi prinsă În plus, există o cale în care X nu se schimbă (cale abd) Dacă există o eroare, atunci aceasta nu va fi detectată Astfel, criteriul de acoperire a operatorului este atât de slab încât nu este utilizat în mod obișnuit O măsură mai puternică a acoperirii logicii programului este cunoscută sub denumirea de acoperire de decizie sau acoperire de tranziție Conform acestui criteriu, trebuie scris un număr suficient de teste astfel încât fiecare soluție a acestor teste să fie evaluată la adevărat și fals cel puțin o dată Cu alte cuvinte, fiecare direcție de tranziție trebuie implementată cel puțin o dată Exemple de instrucțiuni de salt sau de decizie sunt instrucțiuni DO (sau PERFORM UNTIL în Cobol), IF, cu mai multe ieșiri GO TO Se poate demonstra că acoperirea soluției îndeplinește de obicei criteriul de acoperire a operatorului Deoarece fiecare instrucțiune se află pe o cale, fie dintr-o instrucțiune de salt, fie dintr-un punct de intrare în program, fiecare instrucțiune trebuie să fie executată atunci când fiecare direcție de salt este executată Cu toate acestea, există cel puțin trei excepții Prima este o situație patologică în care programul nu are soluții Al doilea apare în programe sau subrutine cu mai multe puncte de intrare; această instrucțiune poate fi executată numai dacă execuția programului începe de la punctul de intrare corespunzător A treia excepție o reprezintă operatorii din unitățile ON; executarea fiecărei direcții de salt nu va determina neapărat executarea tuturor unităților ON Deoarece acoperirea declarațiilor este considerată o condiție necesară, acoperirea deciziei, care pare a fi un criteriu mai puternic, trebuie să includă acoperirea declarațiilor Prin urmare, acoperirea deciziei necesită ca fiecare decizie să fie evaluată la adevărat și fals și ca fiecare declarație să fie executată cel puțin o dată O modalitate alternativă și mai ușoară de a exprima această cerință este ca fiecare decizie să fie evaluată la adevărat și fals și că fiecare punct de intrare (inclusiv unitățile ON) trebuie dar să fie transferat când programul este apelat cel puțin o dată Cele de mai sus presupune doar soluții sau tranziții cu două valori și trebuie modificate pentru programele care conțin soluții cu mai multe valori Exemple de astfel de programe sunt programele PL/ care includ instrucțiuni SELECT (CASE) sau instrucțiuni GO TO folosind etichete de variabile, programe Fortran cu instrucțiuni IF aritmetice, instrucțiuni GO TO calculate sau instrucțiuni GO TO pe bază de prescripție și programe Cobol care conțin GO Instrucțiuni TO împreună cu instrucțiuni ALTER sau GO-TO-DEPENDING-ON Criteriul pentru ele este executarea fiecărui rezultat posibil al tuturor deciziilor cel puțin o dată și transferul controlului la apelarea unui program sau subrutină la fiecare punct de intrare cel puțin o dată În programul prezentat în fig , acoperirea deciziei se poate face prin două teste care acoperă fie căile ace și abd, fie căile aed și abe Dacă alegem ultima acoperire alternativă, atunci intrările celor două teste sunt A= , B= , X= și A= , B= , X=/ Acoperirea deciziei este un criteriu mai puternic decât acoperirea operatorului, dar are și dezavantajele sale De exemplu, o cale în care X nu se schimbă (dacă este selectată prima acoperire alternativă) va fi testată cu o probabilitate de % Dacă există o eroare în a doua soluție (de exemplu, X ), atunci eroarea nu va fi detectată de cele două teste din exemplul anterior Un criteriu mai bun în comparație cu cel anterior este acoperirea stării În acest caz, se înregistrează un număr suficient de teste, astfel încât toate rezultatele posibile ale fiecărei condiții din soluție să fie executate cel puțin o dată Deoarece, ca și în cazul acoperirii deciziilor, această acoperire nu duce întotdeauna la execuția fiecărei instrucțiuni, este necesară o adăugare la criteriu, care constă în faptul că fiecare punct de intrare în program sau subrutină, precum și unitățile ON Nu există astfel de operatori în PL/ , dar pot fi implementați folosind instrumente PL/ Metodele de implementare sunt descrise în cartea: Hughes J , M și ch tom J Abordarea structurală a programării M , Mir, - Notă pe controlul trebuie transferat atunci când este apelat cel puțin o dată De exemplu, instrucțiunea buclă DO K = o TO WHILE (J + K (adică, execuția ultimei iterații a buclei), J + / QUEST Programul fig are patru condiții: A > , B = , A = și X> Prin urmare, este necesar un număr suficient de teste, cum ar fi implementarea situațiilor în care A> , A C , B = și B=I= în punctul a și A = , A=d= , și X ^I la punctul b Teste care îndeplinesc criteriile de acoperire a condiției și căile lor corespunzătoare: = , B= , X= as \u d , B \u d , X \u d abd Rețineți că, deși un număr similar de teste pentru acest exemplu a fost deja creat, acoperirea condiției este de obicei mai bună decât acoperirea deciziei, deoarece poate (dar nu întotdeauna) determina executarea deciziilor în condiții care nu sunt implementate de acoperirea deciziei De exemplu, operatorul DO K = LA WHILE (J + K TABSIZE and NOTFOUND este adevărat (se ajunge la sfârșitul tabelului fără a găsi valoarea dorită) I>TABSIZE și NOTFOUND sunt false (valoarea pe care o căutați este ultima intrare din tabel) Este ușor de observat că o suită de teste care satisface criteriul de acoperire a condiției combinatorii satisface și criteriile de acoperire a deciziei, acoperirea condiției și criteriile de acoperire a deciziei/condiții Conform acestui criteriu, în programul din Fig următoarele opt combinații ar trebui să fie acoperite de teste: L> , v=o > , B#= ^ , B = ^ , B#= = , X> = , X^I #= , X> #= , X^I Rețineți că combinațiile - sunt valorile celei de-a doua instrucțiuni IF Deoarece X s-ar putea să se fi schimbat înainte de executarea acestei instrucțiuni, valorile necesare pentru testarea acesteia trebuie restaurate din logica programului pentru a găsi valorile de intrare adecvate Nu este necesar să folosiți toate cele opt teste pentru a testa aceste combinații De fapt, ele pot fi acoperite de patru teste Iată valorile de testare de intrare și combinațiile pe care le acoperă: = , B = , X= \u d , B \u d , X \u d = , B= , X= = , B= , X= coperți coperți coperți coperți ' Că cele patru teste corespund la patru căi diferite din fig este o coincidență De fapt, testele de mai sus nu acoperă toate căile, ele omit calea aed De exemplu, sunt necesare opt teste pentru a testa următorul program: DACA((X=Y) & (LUNGIME(Z) = ) &END)Atunci J=l; ELSE = ; deși este acoperit doar în două moduri În cazul buclelor, numărul de teste pentru a satisface criteriul de acoperire a condiției combinatorii este de obicei mai mare decât numărul de căi Astfel, pentru programele care conțin o singură condiție per decizie, criteriul minim este unul a cărui suită de teste ) face ca toate rezultatele fiecărei decizii să fie executate cel puțin o dată și ) trece controlul fiecărui punct de intrare (de exemplu, punct de intrare, ON) - unitate) cel puțin o dată (pentru a se asigura că fiecare instrucțiune de program este executată cel puțin o dată) Pentru programele care conțin soluții, fiecare dintre ele având mai mult de o condiție, criteriul minim constă într-un set de teste care provoacă toate combinații ale rezultatelor condițiilor din fiecare decizie și trecerea controlului către fiecare punct de intrare al programului cel puțin o dată [Cuvântul „posibil” este folosit aici deoarece unele combinații de condiții pot să nu fie realizabile; de exemplu, în expresia (A> ) & (A ) Dacă condiția de intrare descrie numărul de valori (de exemplu, „de la una la șase persoane pot merge într-o mașină”), atunci se determină o clasă de echivalență corectă și două incorecte (niciuna și mai mult de șase persoane) Dacă condiția de intrare descrie un set de valori de intrare și există motive să credem că programul interpretează fiecare valoare într-un mod special (de exemplu, „există modalități cunoscute de a călători cu AUTOBUZ, CAMION, TAXI, PICIOARE, sau MOTOCICLETĂ”), atunci se determină clasa de echivalență corectă pentru fiecare valoare și o clasă de echivalență greșită (de ex , „Pe o remorcă”), Dacă condiția de introducere descrie o situație „trebuie să fie” (de exemplu, „primul caracter al identificatorului trebuie să fie o literă”), atunci se definește o clasă de echivalență corectă (primul caracter este o literă) și una este incorectă (primul caracter nu este o literă) Dacă există vreun motiv să credem că diferite elemente ale unei clase de echivalență sunt tratate diferit de program, atunci această clasă de echivalență este împărțită în clase de echivalență mai mici Acest proces va fi ilustrat pe scurt mai jos Teste de clădire Al doilea pas este utilizarea claselor de echivalență pentru a construi teste Acest proces include: - Atribuiți un număr unic fiecărei clase de echivalență Proiectarea de noi teste, fiecare dintre acestea să acopere cât mai multe clase de echivalență obișnuite neacoperite posibil, până când toate clasele de echivalență valide sunt acoperite de teste (dar nu comune) Scrieți teste, fiecare acoperind una și numai una dintre clasele de echivalență greșite descoperite, până când toate clasele de echivalență greșite sunt acoperite de teste Motivul pentru acoperirea claselor de echivalență greșite cu teste individuale este că anumite verificări cu intrări eronate ascund sau înlocuiesc alte verificări cu intrări eronate De exemplu, specificația precizează „tipul de carte care trebuie căutată (INGINERIA INFORMATICĂ, PROGRAMARE sau GENERAL) și cantitatea ( - )” Apoi testați XYZ despre afișează două condiții eronate (tipul de carte și cantitate greșită) și probabil că nu va verifica cantitatea, deoarece programul ar putea răspunde „XYZ ESTE UN TIP DE CARTE INEXISTENT” și să nu verifice restul intrării Exemplu Să presupunem că atunci când se dezvoltă un compilator pentru un subset al limbajului Fortran, este necesar să se testeze verificarea sintaxei operatorului D IMENS ION Specificația este dată mai jos (Această declarație nu este o declarație completă Fortran DIMENSION; specificația a fost mult prescurtată pentru a face din ea un „studiu de caz” Nu trebuie să se creadă că testarea programelor reale este la fel de ușoară ca în exemplele din această carte ) Specificația conține elementele scrise cu litere latine denotă unități sintactice care trebuie înlocuite cu valorile corespunzătoare în declarațiile reale, elementele opționale sunt cuprinse între paranteze drepte, o elipsă indică faptul că elementul care îl precede poate fi repetat de mai multe ori la rând Operatorul DIMENSION este folosit pentru a defini matrice Forma operator DIMENSION: DIMENSIONad[,ad] , unde ad este un descriptor de matrice în formular n(d[,d] ), n este numele simbolic al matricei, iar d este indexul matricei Simbol Numele personale pot conține de la unu la șase caractere, fie litere, fie cifre, cu o literă mai întâi Sunt permisi unul până la șapte indici Formular index [Іb:] ub, unde Іб și ub stabilesc limitele inferioare și superioare ale indexului matricei Limita poate fi fie o valoare constantă de la - la , fie o variabilă întreagă (fără indice) Dacă Іб nu este definit, atunci se presupune că este egal cu unu Valoarea lui ub trebuie să fie mai mare sau egală cu Іb Dacă Іб este definit, atunci poate avea o valoare negativă, zero sau pozitivă Ca toate instrucțiunile, instrucțiunea DIMENSION poate fi continuată pe mai multe rânduri (Sfârșit specificația ) Primul pas este identificarea condițiilor de intrare și determinarea claselor de echivalență din acestea (Tabelul ) Clasele de echivalență din tabel sunt indicate prin numere Următorul pas este construirea unui test care să acopere una sau mai multe clase de echivalență valide De exemplu, testați DIMENSIUNEA A( ) acoperă clasele , , , , , , , , și În continuare, sunt definite unul sau mai multe teste care acoperă clasele de echivalență valabile rămase Da, testează DIMENSIUNEA A ( , J XXXX , KLM, X ), BBB (- : : : : ) acoperă gradele rămase Enumerăm clasele de echivalență incorecte și testele corespunzătoare: ( ) : DIMENSIUNE ( ) : DIMENSIUNE ( ) : DIMENSIUNE ( ) : DIMENSIUNE ( ) : DIMENSIUNE ( ) : DIMENSIUNE ( ) : DIMENSIUNE ( ) : DIMENSIUNE ( ) : DIMENSIUNEA ( ) : DIMENSIUNEA ( ) : DIMENSIUNEA ( ) : DIMENSIUNE ( ) : DIMENSIUNE ( ) : DIMENSIUNE ( ) : DIMENSIUNE ( ) : DIMENSIUNE ( ) A ( ) Al( ) A( O) B B ( , , , , , , , ) B( ,A ( )) B( „ ) C(I , ) C( O, J) D(— : ) D( ) D( : ) D(A( ): ) D( : ) Aceste clase de echivalență sunt acoperite de teste Opțional, cititorul poate compara aceste teste cu un set de teste obținute printr-o metodă specială Deși partiția echivalentă este semnificativ mai bună decât selecția aleatorie a testelor, are totuși dezavantaje (adică, ratează anumite tipuri de teste de înaltă performanță) Următoarele două metode - analiza valorilor limită și utilizarea diagramelor funcționale (diagrame ale relațiilor cauză-efect, grafică cauză-efect) - sunt lipsite de multe dintre deficiențele inerente partiționării echivalente * Condiții de intrare Clasele de echivalență Tabelul Clase de echivalență adecvate Clase de echivalență greșite Numărul de descriptori de matrice Lungimea numelui hmassi-wa Nume matrice unul ( ), > unul ( ) niciunul ( ) ( ), > ( ) Numele matricei începe cu o literă Număr de indici Limită superioară Numele variabilei întreg O variabilă întreagă începe cu litera Constant Limită inferioară definită Limita superioară în raport cu limita inferioară Valoarea limită inferioară Concluzie conține litere ( ) și cifre ( ) da ( ) — ( ) constantă ( ), variabilă întreagă ( ) conține litere ( ) și cifre ( ) da ( ) — — ( ) da ( ), nu ( ) mai mare decât ( ), egal cu ( ) mai contine ceva (nouă) nu ( ) ( ), > ( ) nume element de matrice ( ), altceva ( ) este format din altceva ( ) nu ( ) ( ) mai putin ( ) Operatorul este situat pe mai multe linii negativ ( ) zero ( ), > ( ) constantă ( ), variabilă întreagă ( ) da ( ), nu ( ) nume element de matrice ( ), altceva ( ) ANALIZA VALORILOR LA LIMITĂ Experiența a arătat că testele care examinează condițiile la limită sunt mai utile decât testele care nu le examinează Condițiile limită sunt situații care apar direct pe, deasupra sau sub granițele claselor de echivalență de intrare și ieșire Analiza valorii limită diferă de partiţionarea echivalentă în două privinţe: Alegerea oricărui element din clasa de echivalență ca reprezentativ în analiza valorilor la limită se realizează astfel încât să se verifice fiecare graniță a acestei clase cu un test La elaborarea testelor, sunt luate în considerare nu numai condițiile de intrare (spațiul de intrare), ci și spațiul rezultat (adică, clasele de echivalență de ieșire) Este dificil de descris „bucătăria” analizei valorii la limită, deoarece necesită un anumit grad de creativitate și specializare în problema luată în considerare (De aceea, analiza valorii la limită, ca multe alte aspecte ale testării, se bazează în mare măsură pe inteligența umană ) Cu toate acestea, iată câteva reguli generale pentru această metodă Construiți teste pentru limitele regiunii și teste cu date de intrare incorecte pentru situații de depășire ușoară a regiunii dacă condiția de intrare descrie intervalul De exemplu, dacă intervalul corect de intrare este - , și , , atunci scrieți teste pentru situațiile - , , , , - , și , Construiți teste pentru valorile minime și maxime ale condițiilor și teste mai mari sau mai mici decât aceste valori dacă condiția de intrare satisface un set discret de valori De exemplu, dacă fișierul de intrare poate conține de la la de intrări, atunci obțineți teste pentru , , și de intrări Folosiți regula pentru fiecare condiție de ieșire De exemplu, dacă programul calculează o cheltuială lunară și dacă cheltuiala minimă este de , USD, iar cea maximă este de , USD, atunci creați teste care cheltuiesc de la , USD la , USD și , dolari De asemenea, construiți, dacă este posibil, teste care provoacă un flux negativ și un flux mai mare de , USD Rețineți că este important să verificați limitele spațiului rezultat, deoarece limitele regiunilor de intrare nu reprezintă întotdeauna același set de condiții ca limitele regiunilor de ieșire (de exemplu, când se ia în considerare o rutină de calcul sinus) Este întotdeauna posibil să obțineți un rezultat și în afara regiunii de ieșire, dar merită totuși să luați în considerare această posibilitate Folosește regula pentru fiecare zi liberă termeni De exemplu, dacă sistemul de recuperare a informațiilor afișează cele mai relevante rezumate pe ecranul terminalului în funcție de interogarea de intrare, dar nu mai mult de patru rezumate, atunci construiți teste astfel încât programul să afișeze zero, unu și patru rezumate și un test care ar putea cauza programelor de execuție cu afișare eronată a cinci rezumate Dacă intrarea sau ieșirea programului este un set ordonat (de exemplu, un fișier secvențial, o listă liniară, un tabel), atunci concentrați-vă pe primul și ultimul element al acestui set Încearcă-ți mâna să găsești alte condiții limită Pentru a ilustra necesitatea analizei valorii la limită, se poate folosi programul de analiză a triunghiului dat în cap Pentru a defini un triunghi, valorile de intrare trebuie să fie numere întregi pozitive, iar suma oricăror două dintre ele trebuie să fie mai mare decât a treia Dacă sunt definite partiții echivalente, atunci este recomandabil să definiți o partiție în care această condiție este îndeplinită și o alta în care suma a două numere întregi nu este mai mare decât a treia Prin urmare, cele două teste posibile sunt - - și - - Cu toate acestea, există posibilitatea de a pierde o eroare aici Cu alte cuvinte, dacă expresia din program a fost codificată ca A+B^C în loc de A+B>C, atunci programul ne-ar spune în mod eronat că numerele - - reprezintă un triunghi echilateral regulat Astfel, diferența esențială dintre analiza valorii la limită și partiționarea echivalentă este aceea că analiza valorii la limită investighează situațiile care apar pe și în apropierea granițelor partițiilor echivalente Ca exemplu de aplicare a metodei de analiză a valorii la limită, luați în considerare următoarea specificație a programului MTEST este un program care sortează diverse informații despre examene Intrarea în program este un fișier numit OCR, care conține înregistrări de de caractere Prima intrare reprezintă titlul; conținutul său este folosit ca titlu al fiecărui raport de ieșire Următorul set de intrări descrie răspunsurile corecte la examen Fiecare intrare din acest set conține „ ” ca ultim caracter Prima intrare din coloanele - stabilește numărul de răspunsuri (ia valori de la până la ) Coloanele - conțin informații despre răspunsurile corecte la întrebările numerotate - (orice caracter este perceput ca un răspuns) Intrările ulterioare conțin în coloanele - informații despre răspunsurile corecte la întrebările numerotate - , - etc Al treilea set de intrări descrie răspunsurile fiecărui elev Orez Structuri de înregistrări de intrare pentru programul MTEST dent; orice intrare din acest set are numărul „ ” în a optzecea coloană Pentru fiecare elev, prima intrare din coloanele - conține numele sau numărul acestuia (orice caractere); coloanele - conțin informații despre rezultatele răspunsurilor elevilor la întrebările numerotate - Dacă testul are mai mult de de întrebări, atunci intrările ulterioare ale elevului descriu răspunsurile - , - și așa mai departe în coloanele - Numărul maxim de elevi este de Formatele de înregistrare de intrare sunt prezentate în fig Înregistrările de ieșire sunt: ) un raport ordonat în ordinea lexicografică a identificatorilor elevilor și care arată calitatea răspunsurilor fiecărui elev (procent de răspunsuri corecte) și rangul acestuia; ) un raport similar, dar ordonat după calitate; ) un raport care arată media, mediana și abaterea standard a calității răspunsurilor; ) un raport sortat după numărul întrebării și care arată procentul de elevi care au răspuns corect la fiecare întrebare (Sfârșit specificația ) Să începem să citim metodic caietul de sarcini, identificând precondițiile Prima condiție de intrare la limită este un fișier de intrare gol A doua condiție de intrare este o hartă (înregistrare) a numelui; condiţiile la limită sunt Nu există carte de titlu, cele mai scurte și cele mai lungi titluri Următoarele condiții de introducere sunt prezența înregistrărilor de răspuns corect și prezența unui număr de câmpuri de întrebări în prima înregistrare a răspunsului - nu este o clasă de echivalență pentru numărul de întrebări, deoarece pentru fiecare subset de de intrări se poate întâmpla ceva specific (adică sunt necesare multe intrări) O împărțire acceptabilă a întrebărilor în clase de echivalență este o împărțire în două subseturi: - și - Prin urmare, sunt necesare teste în care câmpul pentru numărul de întrebări ia valori de , , , și Aceste teste acoperă majoritatea condițiilor limită pentru înregistrările de răspuns corect; cu toate acestea, există încă trei situații interesante — înregistrări fără răspuns, înregistrări pentru răspunsuri „multe răspunsuri la întrebare” și înregistrări pentru răspunsuri „puține răspunsuri la întrebare” (de exemplu, numărul de întrebări este de și există trei înregistrări de răspuns) primul caz și o înregistrare a răspunsurilor în al doilea) Astfel, sunt definite următoarele teste: Goliți fișierul de intrare Înregistrarea numelui lipsește Numele are un caracter Numele are de caractere Examen cu o singură întrebare Examen de de întrebări Examen de de întrebări Examen de de întrebări intrebari la examen Câmpul pentru numărul de întrebări are valori non-numerice După înregistrarea numelui, nu există înregistrări ale răspunsurilor corecte Există intrări precum „multe răspunsuri corecte la o singură întrebare” Există intrări precum „puține răspunsuri corecte la o singură întrebare” Următoarele condiții de introducere se aplică răspunsurilor elevilor Testele valorii la limită în acest caz ar părea a fi: elevi Cu valorile selectate ale câmpului numărul de întrebări, este mai interesant să luați în considerare nu , ci de întrebări - Notă pe elev de elevi elevi Există o singură intrare pentru răspunsul studentului, dar există două intrări pentru răspunsurile corecte Înregistrarea răspunsului elevului de mai sus este prima din dosar Înregistrarea răspunsului elevului de mai sus este ultimul din dosar Există două înregistrări ale răspunsurilor elevului, dar există o singură înregistrare a răspunsului corect Înregistrarea răspunsurilor elevului de mai sus este prima din dosar Înregistrarea răspunsurilor elevului de mai sus este ultima din dosar De asemenea, puteți obține un set de teste pentru a verifica limitele de ieșire, deși unele dintre limitele de ieșire (de exemplu, raportul gol ) sunt acoperite de testele date Condițiile limită pentru rapoartele și sunt: elevi (la fel ca testul ); elev (la fel ca testul ); de elevi (la fel ca testul ) Estimările calității răspunsurilor tuturor elevilor sunt aceleași Estimările calității răspunsurilor tuturor elevilor sunt diferite Scorurile de calitate ale unora, dar nu tuturor elevilor sunt aceleași (pentru a verifica corectitudinea calculului rangurilor) Elevul primește un scor de calitate a răspunsului de Elevul primește un scor de calitate a răspunsului de Elevul are cel mai scurt identificator de lungime posibil (pentru a verifica ordinea corectă) Elevul are cel mai lung identificator posibil Numărul de studenți este de așa natură încât raportul are o dimensiune puțin mai mare decât o pagină (pentru a vedea cazul tipăririi pe altă pagină) Numărul de studenți este astfel încât raportul este pe o singură pagină Raportați condiții la limită (medie, mediană, abatere standard): Valoarea medie este maximă (calitatea răspunsurilor tuturor elevilor este cea mai ridicată) Valoarea medie este (calitatea răspunsurilor tuturor elevilor este ) Abaterea standard este egală cu maximul său (un elev primește un punctaj de , iar celălalt - ) Abaterea standard este (toți elevii primesc aceeași notă) Testele și acoperă, de asemenea, limitele medianei Un alt test util descrie o situație în care există elevi (verifică împărțirea cu la calcularea valorii așteptate), dar este identic cu testul Raportul de verificare oferă următoarele teste de valoare limită: Toți elevii răspund corect la prima întrebare Toți elevii răspund greșit la prima întrebare Toți elevii răspund corect la ultima întrebare Toți elevii răspund greșit la ultima întrebare D Numărul de întrebări este astfel încât dimensiunea raportului este puțin mai mare de o pagină Numărul de întrebări este astfel încât raportul este pe o singură pagină Un programator experimentat va fi probabil de acord că multe dintre aceste de teste dezvăluie prezența unor greșeli comune care pot fi făcute în dezvoltarea unui anumit program În plus, majoritatea acestor erori probabil nu ar fi fost detectate dacă s-ar fi folosit o metodă de generare aleatorie a testelor sau o metodă specială de generare a testelor Analiza valorii limită, atunci când este aplicată corect, este una dintre cele mai utile tehnici de proiectare a testelor Cu toate acestea, de multe ori se dovedește a fi ineficient datorită faptului că pare simplu la exterior Cititorul ar trebui să fie conștient de faptul că condițiile de limită pot fi subtile și, prin urmare, dificil de determinat APLICAREA DIAGRAMEI FUNCȚIONALE Unul dintre dezavantajele analizei valorii la limită și ale partiției echivalente este că nu examinează combinațiile de condiții de intrare De exemplu, să presupunem că programul MTEST din secțiunea anterioară eșuează dacă produsul dintre numărul de întrebări și numărul de studenți depășește o anumită limită (cum ar fi cantitatea de memorie) O astfel de eroare nu va fi neapărat detectată prin testarea valorii la limită Testarea combinațiilor de condiții de intrare nu este o sarcină ușoară, deoarece chiar și cu partiția echivalentă construită a condițiilor de intrare, numărul de combinații este de obicei mare astronomic Dacă nu există o modalitate sistematică de a selecta un subset al condițiilor de intrare, atunci, de regulă, este selectat un subset arbitrar, rezultând un test ineficient Metoda diagramelor funcționale sau diagramele relațiilor cauză-efect [ ] ajută la selectarea sistematică a testelor performante Are un efect secundar util, deoarece permite detectarea incompletității și ambiguității în specificațiile originale O diagramă funcțională este un limbaj formal în care este tradusă o specificație scrisă în limbaj natural O diagramă poate fi asociată unui circuit logic digital (rețea logică combinatorie), dar o notație mai simplă (forma de notație) este folosită pentru a o descrie decât forma obișnuită de notație adoptată în electronică Pentru a înțelege metoda diagramelor funcționale, cunoștințele de electronică nu sunt deloc necesare, dar o înțelegere a logicii booleene (adică operatori logici și, sau și nu) este de dorit Construcția testelor prin această metodă se realizează în mai multe etape Specificația este împărțită în secțiuni „de lucru” Acest lucru se datorează faptului că diagramele funcționale devin greoaie atunci când sunt aplicate la specificații mari De exemplu, atunci când un sistem de partajare a timpului este testat, zona de lucru poate fi specificația unei singure instrucțiuni La testarea unui compilator, fiecare operator individual al unui limbaj de programare poate fi considerat o zonă de lucru Specificația definește cauza și efectul Motivul este o singură precondiție sau o clasă de echivalență a precondiției O consecință este o condiție de ieșire sau o transformare a sistemului (efectul rezidual pe care condiția de intrare îl are asupra stării programului sau sistemului) De exemplu, dacă un mesaj către program are ca rezultat o actualizare a fișierului principal, atunci schimbarea acestuia este transformarea sistemului; un mesaj de confirmare ar fi o condiție de ieșire Cauzele și efectele sunt determinate de citirea secvențială (cuvânt cu cuvânt) a specificației În acest caz, sunt evidențiate cuvinte sau expresii care descriu cauze și efecte Fiecărei cauze și efect i se atribuie un număr separat Se analizează conținutul semantic al specificației, care este convertit într-un grafic boolean care leagă cauze și efecte Aceasta este diagrama funcțională Diagrama este adnotată cu restricții care descriu combinații de cauze și/sau efecte care nu sunt posibile din cauza restricțiilor sintactice sau externe Prin trasarea metodică a stărilor de condiție ale diagramei, aceasta este transformată într-un tabel de decizie cu intrări limitate Fiecare coloană a tabelului de decizie corespunde unui test Coloanele din tabelul de decizie sunt convertite în teste Simbolurile de bază pentru scrierea diagramelor funcționale sunt prezentate în fig Fiecare nod al diagramei poate fi în două stări - sau ; indică starea „absent”, iar - „prezent” Funcția de identitate afirmă că dacă valoarea lui a este , atunci și valoarea lui b este ; în caz contrar, valoarea lui b este Funcția nu afirmă că dacă a este , atunci b este ; în caz contrar, b este Funcția sau afirmă că dacă a sau b sau c este , atunci d este ; în caz contrar, d este Funcția și afirmă că dacă a și b sunt , atunci c este ; în caz contrar c este Ultimele două funcții permit orice număr de intrări Pentru a ilustra cele de mai sus, luați în considerare o diagramă care afișează specificația: caracterul din coloana trebuie să fie litera „A” sau „B”, iar în coloana trebuie să fie un număr În acest caz, fișierul este actualizat Dacă primul sim valul este incorect, atunci este emis mesajul XI , iar dacă al doilea caracter este incorect, mesajul X nu Identitate Orez Relații logice de bază ale diagramelor funcționale Motivele sunt - simbolul „A” în coloană ke ; - simbolul „B” în coloană ke ; - numărul din coloana , si consecintele - fișierul este în curs de actualizare; - este emis un mesaj X ; - este emis un mesaj X Schema funcțională este prezentată în fig Rețineți că aici a fost creat un nod intermediar Cititorul ar trebui să verifice dacă diagrama reprezintă de fapt această specificație, dând cauzelor toate valorile posibile și verificând dacă consecințele iau valorile corecte Pentru cititorii familiarizați cu diagramele logice, Fig prezintă circuitul logic echivalent Deși diagrama din fig afișează specificația, conține o combinație imposibilă de cauze - cauzele și nu pot fi setate la în același timp În majoritatea programelor, anumite combinații de motive nu sunt posibile din cauza restricțiilor sintactice sau externe (de exemplu, un simbol nu poate fi „A” și „B” în același timp) În acest caz, sunt utilizate constrângeri logice suplimentare, prezentate în Fig Constrângerea E afirmă că E trebuie să fie adevărată dacă cel puțin una dintre cauze, a sau b, evaluează la (a și b nu pot evalua ambele la în același timp) Constrângerea I afirmă că cel puțin unul dintre a, b sau c trebuie să fie întotdeauna (a, b și c nu pot ia în același timp valoarea ) Restrictia O afirmă că unul și numai unul dintre a sau b trebuie să fie egal cu Constrângerea R afirmă că ce se întâmplă dacă a ia valoarea Orez Exemplu de diagramă funcțională , atunci& trebuie să ia valoarea (adică nu este posibil ca a să fie și b să fie ) Adesea este nevoie de restricții asupra consecințelor Restricția M din fig prevede că dacă consecința a are valoarea , atunci consecința b trebuie să ia valoarea După cum se poate vedea din exemplul de mai sus, este imposibil din punct de vedere fizic pentru Orez Circuit logic echivalent cu schema din fig cauzele și au fost prezente în același timp, dar este posibil ca Unul și numai unul Include a avea unul dintre ei Prin urmare, ele sunt conectate prin constrângerea E (Fig ) Să ilustrăm utilizarea diaguri traditionale Necesită Orez Simboluri de restricție \m Se ascunde Orez Simbol pentru restricție „ascunsă” grame pentru a face teste În acest scop, vom folosi specificația pentru comanda debug într-un sistem interactiv Orez Un exemplu de diagramă funcțională cu constrângerea „exclude” Comanda DISPLAY este utilizată pentru a afișa alocarea memoriei pe ecran Sintaxa comenzii este prezentată în fig Parantezele reprezintă operanzi opționali alternativi Literele mari indică cuvintele cheie ale operanzilor, iar literele precedate de puncte indică valorile operanzilor IHSPL flyY adresa - adresa - END cumpărare contor de ani Orez Sintaxa comenzii DISPLAY (adică valorile reale ale operanzilor care trebuie înlocuiți) Operanzii subliniați corespund valorilor standard (adică, dacă un operand este omis, se presupune valoarea standard) Primul operand (adresa ) specifică adresa primului octet al „zonei de memorie al cărei conținut urmează să fie afișat pe ecran Lungimea adresei este specificată de una până la șase cifre hexazecimale ( - , A-F) Dacă primul operand nu este definit, atunci adresa se presupune a fi Adresa trebuie să ia o valoare dintr-o zonă de memorie validă a mașinii Al doilea operand specifică cantitatea de memorie care trebuie mapată Dacă se specifică adresa , atunci aceasta specifică, la rândul său, adresa ultimului octet al zonei de memorie care urmează să fie afișată pe ecran Lungimea acestei adrese este dată de una până la șase cifre hexazecimale Trebuie să fie mai mare sau egală cu adresa de început (adresa ) La fel, adresa trebuie să ia valori din zona de memorie reală a mașinii Dacă END este specificat ca al doilea operand, memoria este mapată până la ultima adresă validă a mașinii Dacă un contor de octeți este specificat ca operand, atunci acesta determină, la rândul său, numărul de octeți de memorie care trebuie mapați (începând Adresa și adresa sunt hexazecimale - Notă ed din octetul cu adresa adresa ) Operandul de numărare de octeți este un număr întreg hexazecimal (între unu până la șase cifre) Suma valorilor operandului numărul de octeți și adresa nu trebuie să depășească dimensiunea reală a memoriei plus unu, iar numărul de octeți trebuie să aibă cel puțin o valoare de Starea memoriei este afișată pe ecranul terminalului ca una sau mai multe linii din următorul format: xxxxxx = cuvânt cuvânt cuvânt cuvânt , unde xxxxxxx este adresa hexazecimală a cuvântului Numărul total de cuvinte (secvențe de patru octeți în care adresa primului octet din cuvânt este un multiplu de patru) este întotdeauna afișat, indiferent de valoarea adresei operandului sau de cantitatea de memorie afișată Toate liniile de ieșire conțin întotdeauna patru cuvinte ( octeți) Primul octet al zonei de memorie mapată se află în primul cuvânt Pot apărea următoarele mesaje de eroare: M SINTAXA COMANDĂ INCORECTĂ M ADRESA CERATĂ MAI MARE M A CERUT O ZONA DE MEMORIE CU O ADRESĂ NEGATIVE SAU ZERO Exemple de comenzi DISPLAY: AFIŞA afișează primele patru cuvinte din memorie (valoarea implicită a adresei de început este , iar valoarea implicită a contorului de octeți este ); DISPLAY F afișează cuvântul care conține octetul cu adresa F și trei cuvinte ulterioare; DISPLAY F - A afișează cuvintele care conțin octeți de la adresele de la ot F la A; DISPLAY F afișează cuvinte care conțin șase octeți începând cu adresa F; DISPLAY FF-END afișează cuvintele care conțin octeți de la adresa FF până la sfârșitul memoriei Primul pas este să analizați cu atenție cificare în vederea identificării cauzelor și efectelor Motivele sunt: Prezența primului operand Adresa operandului conține doar cifre hexazecimale Adresa operandului conține de la unu la șase , personaje Adresa operandului se află într-o zonă de memorie validă Al doilea operand este END Al doilea operand este adresa Al doilea operand este un numărător de octeți Al doilea operand lipsește Adresa operandului conține doar șaisprezece cifră alfabetică Adresa operandului conține unul până la șase caractere Adresa operandului este în limitele valabile ; zona de memorie Adresa operandului este mai mare sau egală cu adresa operandului Operandul contor de octeți conține doar cifre hexazecimale Operandul contor de octeți conține unul până la șase caractere ( Număr de octeți + dimensiunea memoriei adresa + Număr de octeți :> Zona de memorie solicitată este atât de mare încât necesită multe linii pe ecran Începutul regiunii nu este aliniat la granița unui cuvânt, і Fiecărui motiv îi corespunde un unic arbitrar numărul venelor Rețineți că sunt necesare patru motive ( - ) pentru a descrie al doilea operand, deoarece al doilea operand poate lua valorile ) END, ) adresa , ) numărul de octeți, ) poate fi absent și ) valoare nedefinită, adică niciuna dintre cele de mai sus Consecințe: i Mesajul M este afișat pe ecran I Pe ecran este afișat mesajul M Mesajul M este afișat pe ecran Memoria este afișată pe o linie Afișarea stării memoriei necesită Am multe rânduri eu © © © Orez Versiunea inițială a diagramei funcționale a comenzii DISPLAY Primul octet al zonei de memorie mapată este aliniat la o limită de cuvânt Primul octet al zonei de memorie mapată nu este aliniat cu cuvinte Al doilea pas este dezvoltarea unei diagrame funcționale Cauza nodurilor sunt listate vertical la marginea stângă a paginii; nodurile consecintelor sunt colectate vertical la marginea sa dreapta Conținutul semantic al specificației este analizat cu atenție pentru a lega cauze și efecte (adică, pentru a arăta în ce condiții are loc efectul) Pe fig prezintă versiunea inițială a diagramei Nodul intermediar reprezintă un prim operand corect din punct de vedere sintactic, nodul un al doilea operand corect din punct de vedere sintactic, iar nodul o instrucţiune corectă din punct de vedere sintactic Dacă valoarea nodului este , atunci consecința (mesaj de eroare) lipsește Dacă valoarea nodului este , atunci corolarul este valabil Pe fig prezintă o diagramă funcțională completă Cititorul ar trebui să verifice această diagramă cu atenție pentru a se asigura că reprezintă cu exactitate specificația Dacă diagrama din fig este folosit direct pentru a construi teste, apoi crearea multor dintre ele va fi de fapt imposibilă Acest lucru se datorează faptului că anumite combinații de cauze nu pot apărea din cauza restricțiilor sintactice De exemplu, cauzele și nu pot fi prezente fără cauză Orez Diagrama funcțională completă fără restricții Cauza nu poate fi prezentă dacă nu există cauzele și În fig Figura prezintă diagrama finală cu toate restricțiile suplimentare Notă că poate fi prezent doar unul dintre motivele , , sau Alte constrângeri ale motivelor sunt condițiile de tip care necesită Cauza (multe linii pe ecran) și cauza (al doilea operand lipsește) sunt legate de relația nu \ motivul poate fi prezent numai în absența Influența cauzei Din nou, cititorul trebuie să examineze cu atenție orice restricții impuse condițiilor Al treilea pas este generarea unui tabel de decizie cu intrări limitate Pentru cititorii familiarizați cu tabelele de decizie, cauzele sunt condiții și efectele sunt sunt actiuni Procedura de generare este următoarea: Selectați o consecință care ar trebui să fie în starea Găsiți toate combinațiile de cauze (supuse restricțiilor) care vor seta acest efect la , urmărind acest efect prin diagramă Construiți o coloană în tabelul de decizie pentru fiecare combinație de motive Pentru fiecare combinație de cauze, determinați stările tuturor celorlalte efecte și plasați-le în coloana corespunzătoare a tabelului de decizie Există trei lucruri de care trebuie să țineți cont atunci când faceți acest pas: Dacă calea inversă este așezată prin nod sau, a cărei ieșire trebuie să ia valoarea , atunci mai mult de o intrare în acest nod nu trebuie setată la în același timp Această constrângere privind setarea valorilor de intrare se numește sensibilitate a căii Scopul acestei reguli este de a evita ratarea anumitor erori deoarece o cauză este mascata de alta Dacă o urmă inversă este direcționată printr-un nod u a cărui ieșire trebuie să ia valoarea , atunci toate combinațiile de intrări care aduc ieșirea la trebuie în cele din urmă enumerate Cu toate acestea, atunci când examinăm o situație în care o intrare este și una sau mai multe alte intrări sunt , nu este necesar să enumerați toate condițiile în care intrările rămase pot fi Dacă următorul invers este așezat prin nod și, a cărui ieșire trebuie să ia valoarea , atunci este necesar să se specifice o singură condiție, conform căreia toate intrările sunt zero (Când un nod se află în mijlocul graficului, iar intrările sale provin de la alte noduri intermediare, poate exista un număr extrem de mare de situații în care toate intrările sale sunt ) Aceste prevederi sunt explicate pe scurt în Fig Orez este dat ca exemplu de diagramă funcțională Să fie necesar să se stabilească condițiile de intrare în așa fel încât să se stabilească starea de ieșire la Conform Propoziției , ar trebui luat în considerare un singur caz când nodurile și sunt zerouri Conform poziției , pentru starea în care nodul ia valoarea , iar nodul ia valoarea O, ar trebui luat în considerare un singur caz când nodul ia valoarea (fără a enumera alte cazuri posibile când nodul poate lua valoarea ) valoare Stat Si tuaiiya Orez Pozițiile utilizate la așezarea urmei din spate prin diagramă: Dacă X ar trebui să fie egal atunci nu trebuie să luați în considerare situația în care a=&= (poziția ) Dacă X trebuie să fie egal cu , atunci enumerați toate situațiile în care a= = Dacă X trebuie să fie egal cu , atunci enumerați toate situațiile în care a=b-c==\ Dacă X trebuie să fie egal cu , atunci considerăm o singură situație, unde a= =c= (poziția ), Pentru stările a, b și c , , , , și PO luați în considerare doar una, oricare dintre aceste situații (poziția ) ) În mod similar, pentru o stare în care nodul este setat la și nodul este setat la , ar trebui luat în considerare doar un caz în care nodul este setat la (deși acesta este singurul caz în acest exemplu) Conform clauzei , dacă nodul trebuie să fie setat la starea , nu se recomandă setarea nodurilor și la starea în același timp Astfel, sunt posibile cinci stări ale nodurilor - , de exemplu, valorile Orez Un exemplu de diagramă funcțională pentru a ilustra trasarea înapoi ( = , = ) ( = , = ) ( = , = ) ( = , = ) ( = , = ) -nu , ceea ce duce la o stare de ieșire de La prima vedere, aceste prevederi pot părea părtinitoare, dar au un scop important: reducerea combinatoriei diagramei Utilizarea lor permite evitarea situațiilor care duc la teste ineficiente Dacă nu excludem testele cu performanță scăzută, atunci numărul total de teste generate dintr-o diagramă funcțională mare este astronomic Dacă, chiar și fără ele, numărul de teste este încă mare, atunci este selectat un subset de teste, dar nu este garantat că testele cu performanță scăzută vor fi excluse Prin urmare, cel mai bine este să le excludeți în procesul de analiză a diagramei Să transformăm diagrama funcțională prezentată în Fig , la tabelul de decizie Alegem ca prim corolar corolarul Corolarul apare dacă nodul ia valoarea Valoarea nodului este dacă valoarea nodurilor și este , , , sau , și se aplică afirmațiile și transformarea este un proces laborios, dar este posibil să se urmărească de la efecte la cauze, ținând cont de „limitările cauzelor și găsirea de combinații ale acestora din urmă care conduc la efect” Tabelul de decizie rezultat, cu condiția ca Corolarul să fie valabil, este prezentat în Fig (coloanele - ) Coloanele (testele) - reprezintă condiții în care nodul este și nodul este Coloanele - reprezintă condiții în care nodul este și nodul este O singură situație este definită folosind clauza (coloana ) din cele posibile atunci când nodurile și sunt Spațiile reprezintă situații „indiferente” (adică starea cauzei este imaterială) sau indică faptul că starea cauzei este evidentă datorită stărilor altor cauze dependente (de exemplu, pt coloana se știe că cauzele , și trebuie să ia valorile , deoarece sunt legate de constrângerea „unul și singurul” la cauza ) Coloanele - reprezintă situaţii în care Corolarul este valabil, iar coloanele și arată situații în care Corolarul este valabil arată restul tabelului de decizie Ultimul pas este convertirea tabelului de decizie în de teste Un set de de teste g i t t V optsprezece sau Orez Prima jumătate a tabelului rezultat factorii de decizie prezentat mai jos Cifrele de lângă fiecare test indică consecințele care se așteaptă să aibă loc aici Să presupunem ultima adresă de memorie utilizată; mașinile au FFF h b b Yu / Orez A doua jumătate a tabelului de decizie rezultat DISPLAY AF — ( ) DISPLAY ZX — ( ) DISPLAY HHHHHHHH— ( ) DISPLAY ( ) DISPLAY - ( ) DISPLAY - X ( ) DISPLAY —ABCDEFGHI ( ) DISPLAY ( ) DISPLAY S ( ) AFIȘARE $$$$$$$ ( ) DISPLAY —M ( ) DISPLAY FF - ( ) DISPLAY FFF ( ) DISPLAY - END ( ) DISPLAY - ( ) DISPLAY AA—A ( ) DISPLAY ( ) DISPLAY FF - END ( , ) DISPLAY ( , * DISPLAY - ( , } DISPLAY A ( , ) AFIȘARE - sfârșit ( , ) DISPLAY ( , ) DISPLAY - F ( , ) DISPLAY ,E ( , ) DISPLAY FF - END ( , }) DISPLAY ( , ) DISPLAY AO—A ( , ) DISPLAY , ( , ) DISPLAY - END ( , ) DISPLAY - ( , ) DISPLAY FF ( , ) AFIȘARE - sfârșit ( , ) DISPLAY - ( , ) DISPLAY ( ) DISPLAY - END ( , ) DISPLAY - ( , ) DISPLAY ( ) Rețineți că atunci când două sau mai multe teste diferite corespund aceluiași set de cauze, ar trebui să încercați să alegeți valori diferite ale cauzelor pentru a îmbunătăți performanța testelor chiar și ușor Rețineți, de asemenea, că, din cauza dimensiunii limitate a memoriei, Testul este irealizabil („folosirea acestuia va avea ca rezultat Corolarul în loc de , așa cum este menționat în Testul ) Prin urmare, doar de teste sunt realizabile Remarci Utilizarea diagramelor funcționale este o metodă sistematică de generare a testelor reprezentând combinații de condiții Alternativa este selecția ad-hoc a combinațiilor, dar există posibilitatea de a pierde multe dintre testele „interesante” identificate de diagrama funcțională Când se utilizează diagrame funcționale, este necesară traducerea specificației într-o rețea logică booleană Prin urmare, această metodă deschide perspective pentru aplicarea sa și posibilități suplimentare pentru specificații Într-adevăr, dezvoltarea diagramelor funcționale este o modalitate bună de a detecta incompletitudinea și ambiguitatea în specificațiile originale De exemplu, cititorul poate observa că procesul propus dezvăluie o caracter incomplet în specificația comenzii DISPLAY Specificația afirmă că toate ieșirile Noile rânduri conțin patru cuvinte Acest lucru nu este adevărat în toate cazurile; de exemplu, pentru testele și acest lucru nu este adevărat, deoarece pentru ele adresa de început a memoriei mapate diferă de adresa de final a memoriei mașinii cu mai puțin de octeți Metoda diagramei funcționale vă permite să construiți un set de teste utile, dar aplicarea acestuia de obicei nu oferă construcția tuturor testelor utile care pot fi definite Deci, în exemplul nostru, nu am spus nimic despre verificarea identității valorilor datelor afișate pe ecranul terminalului cu datele din memorie și despre stabilirea cazului în care programul poate afișa orice valoare posibilă stocată în celula de memorie pe ecran În plus, diagrama funcțională nu explorează în mod adecvat condițiile la limită Desigur, în procesul de lucru cu diagrame funcționale, puteți încerca să acoperiți condițiile limită De exemplu, în loc să definiți un singur motiv adresa adresa pot fi identificate două motive adresa = adresa adresa > adresa Cu toate acestea, în acest caz, graficul devine mult mai complicat, iar numărul de teste devine extrem de mare Prin urmare, este mai bine să separați analiza valorilor limită de metoda diagramelor funcționale De exemplu, pentru specificarea unei comenzi DISPLAY, pot fi definite următoarele condiții limită: Adresa are o cifră Adresa are șase cifre Adresa are șapte cifre Adresa = Adresa = FFF Adresa = Adresa are o cifră Adresa are șase cifre Adresa are șapte cifre Adresa = I Adresa = FFF Adresa = Adresa =adresa Adresa =adresa /+ Adresa =adresa - Număr de octeți lung de o cifră Contor de octeți lungime de șase cifre Contor de octeți lung de șapte cifre Număr de octeți = Adresa + contor octet = Adresa + contor octet= Afișați șaisprezece octeți (o linie) Afișare de șaptesprezece octeți (două linii) Acest lucru nu înseamnă că ar trebui să scrieți de teste ( + ) Deoarece diagrama funcțională oferă doar îndrumări în alegerea anumitor valori ale operanzilor, condițiile la limită pot fi incluse în testele derivate din aceasta În exemplul nostru, prin rescrierea unora dintre cele de teste originale, putem acoperi toate cele de condiții la limită fără teste suplimentare Astfel, obținem o suită de teste mică, dar convingătoare, care ne satisface obiectivele Rețineți că metoda diagramelor funcționale este în concordanță cu unele dintre principiile de testare prezentate în Cap Partea sa integrantă este definirea rezultatului așteptat al fiecărui test (toate coloanele din tabelul de decizie indică consecințele așteptate) De asemenea, rețineți că această metodă ajută la identificarea efectelor secundare eronate De exemplu, coloana (testul) afirmă că consecința trebuie să fie prezentă și că consecințele - trebuie să fie absente Cel mai dificil lucru în implementarea metodei este transformarea diagramei într-un tabel de decizie Această transformare este un proces algoritmic Prin urmare, poate fi automatizat prin scrierea unui program adecvat IBM are o serie de astfel de programe, dar nu le furnizează Un alt exemplu de aplicare a diagramelor funcționale poate fi găsit în [ ] PREZUMEREA DE EROARE S-a observat că unii oameni, în virtutea calităților lor, se dovedesc a fi excelenți testeri de programe Ei au capacitatea de a „depista” erorile fără a recurge la vreo metodologie de testare (cum ar fi analiza valorii la limită sau utilizarea diagramelor funcționale) Acest lucru se explică prin faptul că o persoană care are experiență, adesea subconștient aplică o tehnică de proiectare a testelor numită ghicirea erorilor Având în vedere un anumit program, acesta își asumă în mod intuitiv tipurile probabile de erori și apoi dezvoltă teste pentru a le detecta Procedura pentru metoda de estimare a erorilor este dificil de descris deoarece este în mare parte intuitivă Ideea sa principală este să enumere posibile erori sau situații în care acestea pot apărea într-o listă, iar apoi să scrie teste pe baza acestei liste De exemplu, o astfel de situație apare atunci când valoarea la intrarea și la ieșirea programului Prin urmare, este posibil să se construiască teste pentru care anumite intrări sunt nule și pentru care anumite ieșiri sunt setate la Când numărul de intrări sau ieșiri este variabil (de exemplu, numărul de înregistrări de intrare de căutat într-o căutare în listă) , erorile sunt posibile în situații precum „niciunul” și „unu” (de exemplu, o listă goală, o listă care conține o singură intrare căutată) O altă idee este de a defini teste legate de ipotezele pe care programatorul le-ar putea face în timp ce citește specificațiile (adică lucruri care au fost omise din specificație, fie din întâmplare, fie pentru că autorul specificației a crezut că sunt evidente) Deoarece această procedură nu poate fi definită în mod clar, cel mai bun mod de a discuta semnificația ipotezei de eroare este să se uite la exemple Dacă luăm în considerare testarea unei rutine de sortare ca exemplu, atunci trebuie să investigăm următoarele situații: Lista sortabilă este goală Lista de sortat conține o singură valoare Toate intrările din lista sortată au aceeași valoare* Lista este deja sortată Cu alte cuvinte, este necesar să se enumere acele cazuri speciale care ar putea să nu fie luate în considerare la proiectarea unui program Dacă exemplul este de a testa o rutină de căutare binară, atunci pot fi testate următoarele situații: ) există o singură intrare în tabel care este căutată; marimea ea tabelele sunt o putere de doi (de exemplu, ); ) dimensiunea tabelului este mai mică sau mai mare decât o putere de doi (de exemplu, , ) Luați în considerare programul MTEST prezentat în secțiunea privind analiza valorii la limită Când testați acest program utilizând metoda ghicirii erorilor, este util să luați în considerare următoarele teste suplimentare: Programul permite „spațiu” ca răspuns? O înregistrare de tip (răspuns) apare într-un set de înregistrări de tip (student) O intrare fără sau în ultima coloană nu apare ca intrare inițială (nume) Doi elevi au același nume sau număr Deoarece mediana este calculată diferit în funcție de numărul de elemente par sau impar, trebuie să testați programul atât pentru un număr par, cât și pentru un număr impar de studenți Câmpul numărul de întrebări are o valoare negativă nu Pentru comanda DISPLAY din secțiunea anterioară, merită să luați în considerare următoarele teste ale metodei de estimare a erorilor: DISPLAY —(al doilea operand incomplet) DISPLAY (al doilea operand incomplet) DISPLAY - A (valoarea operandului prea mare) DISPLAY - QFF (zerouri în stânga) •STRATEGIE Metodologiile de proiectare a testelor discutate în acest capitol pot fi combinate într-o strategie comună Motivul combinării lor devine acum evident: fiecare metodă oferă un set specific de teste utilizabile, dar niciuna dintre ele singur nu poate produce un set complet de teste O strategie acceptabilă este următoarea: Dacă specificația conține combinații de condiții de intrare, atunci se recomandă să începeți cu utilizarea metodei diagramelor funcționale În orice caz, trebuie să utilizați analiza valorilor limită Amintiți-vă că această metodă „patru include analiza valorilor limită ale variabilelor de intrare și de ieșire Analiza valorii limită oferă un set de condiții de testare suplimentare, dar așa cum s-a menționat în secțiunea privind diagramele funcționale, multe dintre ele (dacă nu toate) pot fi incluse în testele metodei diagramei funcționale Determinați clasele de echivalență corecte și incorecte pentru datele de intrare și ieșire și completați, dacă este necesar, testele construite în pașii anteriori Pentru teste suplimentare, se recomandă utilizarea metodei de estimare a erorilor Verificați logica programului pe setul de teste primit Pentru a face acest lucru, trebuie să utilizați criteriul de acoperire a deciziei, acoperire de condiție, acoperire de decizie/condiție sau acoperire combinatorie * condiție (cel din urmă criteriu este mai complet) Dacă necesitatea îndeplinirii criteriului de acoperire duce la construirea unor teste care nu se regăsesc printre cele construite în cei patru pași anteriori și dacă acest criteriu nu este irealizabil (adică anumite combinații de condiții nu pot fi create datorită naturii program), atunci setul deja construit de teste ar trebui completat cu teste al căror număr este suficient pentru a satisface criteriul de acoperire Această strategie, din nou, nu garantează că toate erorile vor fi găsite, dar oferă un compromis acceptabil Implementarea unei astfel de strategii este foarte laborioasă, dar nimeni nu a susținut vreodată că testarea unui program este o sarcină ușoară LITERATURĂ Grafice cauză-efect Elmendorf WR în testarea funcțională TR- , IBM Systems Development Division, Poughkeepsie, N Y „ M ers GJ Software Reliability: Principii și practici New "York, Wiley-Interscience, Traducere rusă: Myers G Software reliability M , Mir, CAPITOLUL TESTARE MODULE Având în vedere problemele de testare, până acum am ignorat în mare măsură factori precum organizarea procedurii de testare și dimensiunea programelor testate Cu toate acestea, trecerea la programe mari ( de instrucțiuni sau mai mult) necesită modalități speciale de structurare a procesului de testare În acest capitol, ne vom uita la pasul inițial de structurare, testarea unitară Următorii pași sunt discutați în Cap Testarea unitară (sau bloc) este procesul de testare a subrutinelor individuale sau a procedurilor programului Acest lucru implică faptul că înainte de a începe să testați programul în ansamblu, ar trebui să testați modulele mici individuale care alcătuiesc acest program Această abordare este motivată de trei motive În primul rând, devine posibil să se controleze combinatoria testării, deoarece inițial atenția se concentrează asupra modulelor de program mici În al doilea rând, este facilitată sarcina de depanare a programului, adică găsirea locului erorii și corectarea textului programului În cele din urmă, în al treilea rând, paralelismul este permis, ceea ce vă permite să testați simultan mai multe module Scopul testării modulelor este de a compara funcțiile implementate de un modul cu specificațiile funcțiilor sau ale interfeței sale Subliniem că același scop este propus în formularea generală a problemei de testare, iar problema nu este de a stabili corespondența modulului cu specificația, ci de a arăta contradicția dintre ele Procesul de testare a modulelor este luat în considerare în trei aspecte: modalități de construire a seturilor de testare, ordinea în care modulele sunt testate - « sunt colectate și asamblate într-un program și câteva recomandări practice pentru implementarea testării PROIECTARE DE TESTARE La proiectarea testelor pentru modulele de testare, trebuie să fie disponibile două surse de informații: specificația modulului și textul acestuia Specificația conține de obicei o descriere a parametrilor de intrare și de ieșire ai modulului și a funcțiilor acestuia Testarea unitară se concentrează în principal pe Codul Numele postului Departamentul Salariu ——J Masa angajaților Sumă Departamentul de vanzari Masa din delod Orez Tabel de introducere a modulelor BONUS principiul cutiei albe Acest lucru se datorează în primul rând faptului că principiul cutiei albe este mai dificil de implementat atunci când se trece ulterior la testarea unităților mai mari, cum ar fi programele în ansamblu În plus, etapele ulterioare ale testării sunt concentrate pe detectarea erorilor de diferite tipuri, adică erori care nu sunt neapărat legate de logica programului, dar care apar, de exemplu, din cauza programului care nu îndeplinește cerințele utilizatorului Prin urmare, procedura de creare a unei suite de testare pentru modulele de testare este următoarea: logica unui singur modul este analizată folosind una sau mai multe metode cutie albă, iar apoi această suită de teste este analizată - stov este utilizat la testarea cu metode cutie neagră conform specificațiilor modulului Să ilustrăm utilizarea metodelor de construcție a testelor descrise în Cap , la testarea modulelor Să presupunem că trebuie să testăm modulul BONUS Funcția acestui modul este de a crește cu USD mărimea TESTAREA MODULULUI BONUS: PROCEDURĂ (EMPTAB, DEPTTA B, ESIZE, DSIZE, ERRCODEL ; DECLARE EMPTAB (♦), NAHE CHAR ( ) , COD CHAR ( ) , DFPTCHAR( ) , SALARIU PIXED DECIMAL( , ) ; DECLARE DEPTTAB (*), DEPTCHAR( ) , VÂNZĂRI FIX DEC IM AL ( , ) , DECLARE (DIMENSIUNE, DST ZE) FIX INAR; DECLARE ERRCODE FIXED DECIHAL( ); DECLARE KAXSALES FIXED DEC I AL (R, ) INIT(O); /-MAX VÂNZĂRI ÎN DEF'ThB*/' DECLARE (I,J,K) BINARI FIX; /'CONTARE*/ DECLARE POUND BIT( ); /'TRUE IF LLIGIBLE DEP ARE ANGAJATI"/ DECLARE SINC FIXED DECIMAL( , ) IUIT ( C , ) ; /-STANDARD INCREMENT*/ DECLARE LINC PIXED DECIMAL( , ) IN T ( ) ; /'LOdER INCREMENT*/ DECLARE LSALARY FIXED DECIMAL( , ) IN IT ( ) ; /'LIMITĂ SALARII-/ DECLARE MGR CHAP( ) INIT('M'); ERRCODE= ; IF(SIZE =MAXSALFS) GEM MAXSALES-SAL: (I) ; sfârșit; DO J = LA DIMENSIUNEA; DACĂ (VÂNZĂRI(J)-VÂNZĂRI MAX ) /•DEPARTAMENT ELIGIBIL-/ ATUNCI FĂ; LIBRE=' 'B; DO K = PENTRU DIMENSIUNEA; DACĂ (DEPT EMPTAB (K) = DEPTT A B D EP T (J) ) IU ATUNCI FACE; FC ND=' 'D; DACĂ(SALARUL(K) >= LSALARY) | (COD(K)=HG ) ATUNCI SALARI (K)-SALAR I (K) ♦ LI NC; ELSE SALARIU (K) -SALARI { =VÂNZĂRI MAX ) IF(VÂNZĂRI(J)=VÂNZĂRI MAX ) IF (DEPTAB DEPT(K) = DEPTTAB DEPT(J)) DACĂ(SALARU(K) >=LSALAR) | (COD(K)=MGR) DACĂ (P GĂSIT) Numărul de soluții este mic, astfel încât este probabil să fie aleasă acoperirea multor condiții, dar toate criteriile de acoperire logică (cu excepția acoperirii declarațiilor, care nu este practică) ar trebui testate pentru a lua în considerare performanța lor Pentru a satisface criteriul de acoperire a deciziei este necesară construirea unor teste care să conducă la executarea fiecăreia dintre cele șase instrucțiuni în ambele sensuri Situațiile de intrare necesare pentru aceasta sunt prezentate în Tabelul Sunt situații care patru Tabelul Situații corespunzătoare rezultatelor deciziei Decizie Rezultat adevărat Rezultat fals ESIZE sau DSIZE Apare cel puțin o dată Comanda în DEPTTAB este de așa natură încât departamentul cu cel mai scăzut nivel de vânzări urmează departamentul cu cel mai mare nivel de vânzări din lista de departamente Se întâmplă cel puțin o dată Toate departamentele au niveluri diferite de vânzări Există un angajat care nu este listat în departamentul corespunzător Există un angajat în departamentul relevant Angajat eligibil - manager fie câștigă LSALARY sau mai mult Angajat eligibil - non-manager și câștigă mai puțin de LSALARY Departamentul corespondent nu are angajați Departamentul corespondent are cel puțin un angajat Test Intrare A -a ieșire estimată ESIZE= Valorile tuturor celorlalte variabile similare sunt arbitrare ERRCOBE = ESIZE, BSIZEEMPTRB și depthb nu se modifică ERRCOBE = ESIZE DSIZE și VERTT^ nu se modifică EMRTYAV Jones F D , Smith E B , Lorin E D , B , B , ESIZE=BSIZE= Îmi mănânc gura în RETTYAV Jones E B , Smith E B , Lorin E B , Orez Teste care satisfac criteriul de acoperire a deciziei trebuie verificat cu teste, deoarece vor avea loc întotdeauna două direcții de ramificație Rețineți că atunci când construiți tabelul direcțiile de ieșire din declarațiile de decizie ar trebui urmărite în logica programului; aceasta va face posibilă estimarea condiţiilor de intrare necesare De exemplu, decizia nu este îndeplinită de niciunul dintre salariații întâlniți în condiții, ci doar de un angajat al departamentului corespunzător Zece situații de interes pentru noi din Tabel , luni o sută poate fi verificată folosind cele două teste prezentate în Fig Fiecare test, așa cum este descris în cap include valorile așteptate ale cantităților de ieșire Evident, deși testele îndeplinesc criteriul de acoperire a deciziei, în modul pot rămâne multe tipuri de erori pe care nu le detectează De exemplu, aceste teste nu analizează situația când codul de eroare este , angajatul este manager sau tabelul de departament (DSIZE^O) este gol Dacă utilizați metoda de acoperire a stării, puteți obține un test mai acceptabil Această metodă presupune că testele trebuie să aibă ca rezultat ambele rezultate ale fiecărei condiții din declarația de decizie În tabel prezintă condiţiile cerute tabel Situații corespunzătoare ieșirilor de condiție Termeni Valoarea reală de ieșire Valoare de ieșire falsă ESIZE^O DSIZE^O VÂNZĂRI(I)> MAXSALES ESIZE LSALARY COD(K) = = MGR GĂSITE Se întâmplă măcar o dată Există un angajat în acest departament Acest angajat are un salariu LSALARY sau mai mare Acest angajat este manager Nu există angajați în acest departament ESIZE> DSIZE> Comanda în DEPTTAB este astfel încât un departament cu o sumă mai mică de vânzări se întâlnește mai târziu decât un departament cu o sumă mai mare Toate departamentele au niveluri diferite de vânzări Există un angajat care nu este listat în departamentul corespunzător Acest angajat este plătit mai puțin LSALARY Acest angajat nu este manager Există cel puțin un angajat în acest departament mi-au situațiile de intrare și rezultatele lor de ieșire corespunzătoare Pentru orice condiție, există două situații de intrare și două de ieșire de luat în considerare, așa că testele ar trebui să verifice situații în total Și din nou acestea Tutațiile pot fi verificate prin două teste, care sunt prezentate în Fig Pentru ilustrare în fig Tabelul prezintă testele care satisfac metoda de acoperire a condiției deoarece conduc la executarea tuturor rezultatelor de ieșire indicate în Tabelul Cu toate acestea, aceste teste sunt probabil Test Intrare Ieșire estimată E iZE=OSlZE=O Valorile tuturor celorlalte variabile de intrare sunt arbitrare ERRCO E = ESIZE, OS E, EMRTHV și VERT aph nu se modifică ERRCOBE- ES/ZE BS ZE și DEPTTPB nu se modifică Îmi mănânc gura Jones E Smith E , Lorin M ES ZE=DSIZE= EAT RTR IN VERT TO IN Jones E , J , Smith E , D , Gorin m , , Orez Testele care satisfac criteriul de acoperire a condiției sunt mai rapide decât testele din Fig satisfacerea criteriului de acoperire a soluției Ideea este că ele nu determină executarea fiecărei instrucțiuni; instrucțiunea nu este niciodată executată Performanța lor nu este mai mare decât cea a testelor din Fig Aici este imposibilă situația de ieșire ERRCODE = Dacă, de exemplu, introducerea condiției (ESIZE = )&(DSIZE = ) în instrucțiunea este eronată, atunci această eroare nu va fi detectată Desigur, această problemă poate fi rezolvată prin utilizarea unor suite de teste suplimentare, dar rămâne faptul că testele prezentate în Fig satisface criteriul de acoperire a condiției Folosind criteriul de acoperire a condiției, este posibil să se demonstreze deficiențele setului de teste din Fig Să construim teste care să asigure că fiecare ieșire din toate condițiile și toate soluțiile este executată cel puțin o dată Acest lucru poate fi realizat făcându-l pe Jones managerul testului și pe Lauryn ca non-manager Ca urmare, ambele ramuri ale deciziei și declarației vor fi executate Cu toate acestea, acest set de testare nu este în esență mai bun decât setul de testare din Fig Dacă compilatorul utilizat nu mai evaluează expresia sau de îndată ce una dintre declarații este evaluată la adevărat, atunci rezultatul expresiei CODE(K)=MGR din instrucțiune pe nu va evalua niciodată drept adevărat Prin urmare, dacă această expresie nu este codificată corect, atunci această eroare nu va fi detectată de suita de teste Ultimul lucru pe care îl studiem este criteriul de acoperire combinatorie a condițiilor Acest criteriu necesită ca setul corespunzător de teste să conducă la executarea tuturor combinațiilor posibile de condiții în fiecare soluție Test Intrare Ieșire estimată t ESIZE= DSIZE= Valori pentru toate celelalte variabilele de intrare sunt arbitrare ” ESIZE = O DSIZE > Valori pentru toate celelalte variabilele de intrare sunt arbitrare ESIZE >O DS ZE = O c Valorile tuturor celorlalte variabile de intrare sunt arbitrare ESIZE= DSIZE= ERRCODE= ESIZE, DSIZE, EMPTflB și DE^TTRB nu se modifică La fel La fel EMRTIA DEPTTRB Jones I Db , D , Varna m D , D , Lorin E D W , D Jucărie E D , D , Smith E , ERR DE= ESIZE, DSIZE și DEPTTPB nu se modifică EMPTRB JONES m DP , Warne I D Osetia de Sud, Lauryn E ^ , Jucărie E D iB Smith E T , Orez Teste care satisfac criteriile pentru acoperirea combinatorie a afecțiunilor Vom folosi să luăm în considerare tabelul Oricare dintre soluțiile , , și are două combinații de condiții, iar oricare dintre soluțiile și are patru combinații Conform metodologiei utilizate pentru construirea testelor, trebuie să alegeți mai întâi testul care acoperă numărul maxim de combinații, apoi testul care acoperă numărul maxim de combinații dintre cele rămase și așa mai departe Figura prezintă o suită de teste care satisface criteriul acoperirii condiției combinatorii Acest set este mai de înțeles decât precedentele și ni se pare că tocmai asta ar fi trebuit ales de la bun început Este important de menționat că modulul BONUS poate conține un număr semnificativ de erori care nu pot fi detectate nici măcar printr-un test care îndeplinește criteriul acoperirii condiției combinatorii De exemplu, nici un test ioa nu poate reproduce situația în care valoarea de ieșire ERRCODE este returnată cu o valoare zero Astfel, dacă instrucțiunea este omisă, eroarea nu va fi detectată De asemenea, nu va fi detectată o eroare dacă constanta LSALARY este setată la # la inițializare sau dacă SALARY(K) >LSALARY este scris în instrucțiunea în loc de SALARY(K)^^LSALARY De regulă, erorile umane (de exemplu, ultima intrare în DEPTTAB sau EMPTAB a fost făcută incorect) pot fi descoperite doar întâmplător Din cele de mai sus rezultă că, în primul rând, criteriul de acoperire combinatorie a condițiilor depășește toate celelalte criterii și, în al doilea rând, niciunul dintre criteriile de acoperire logică nu poate fi utilizat ca singurul mijloc pe baza căruia sunt construite testele de module Prin urmare, este necesar să faceți următorul pas și să combinați testele prezentate în Fig , cu un set de teste cutie neagră În acest scop, luați în considerare specificația interfeței modulului BONUS de mai jos BONUS este un modul scris în PL/ , primește cinci parametri, denumirile lor simbolice sunt EMPTAB, DEPTTAB, ESIZE, DSIZE, ERRCODE; aceste opțiuni au următoarele atribute: DECLARE EMPTAB (*), /*intrare și ieșire*/ PERSONAJ NUME ( ), COD CARACTER ( ), PERSONAJ DEPARTAMENT ( ), SALARIU FIX DECIMAL( , ); DECLARE DEPTTAB (*), /*input*/ PERSONAJ DEPARTAMENT ( ), VÂNZĂRI FIX DECIMAL( , ) ; DECLARE (DIMENSIUNE, DSIZE) BINAR FIX; /*intrare*/ DECLARE ERRCODE FIXED DECIMAL( ); /*intrare*/ Argumentele transmise de modul au atributele enumerate mai sus în specificație ESIZE și DSIZE specifică numărul de valori de intrare în EMPTAB și, respectiv, DEPTTAB Ordinea valorilor de intrare în EMPTAB și DEPTTAB nu contează Funcția modulului este de a crește salariul (EMPTAB, SALARIU) angajatului departamentului sau departamentelor cu cea mai mare cantitate de vânzări (DEPTTAB VANZĂRI) Dacă un angajat primește un salariu de de dolari și mai mult, sau dacă este manager (EMPTAB CODE="M"), atunci creșterea salariului este de USD; în toate celelalte cazuri - de dolari Creșterea salarială se înregistrează în câmpul EMPTAB SALARIU Dacă ESIZE și DSIZE sunt mai mici decât zero, este generat un cod de eroare ERRCODE egal cu , „Și nu se întreprinde nicio altă acțiune În toate celelalte situații, funcțiile modulului sunt complet executate Cu toate acestea, dacă departamentul având valoarea maximă a vânzărilor, numărul de angajați este zero, apoi variabilei ERRCODE i se atribuie o valoare egală cu ; în toate celelalte cazuri, valoarea este Această specificație nu poate fi utilizată pentru a construi diagrame funcționale (nu conține un set explicit de condiții de intrare, a căror combinație trebuie investigată), prin urmare, se recomandă metoda de analiză a valorii la limită Sunt definite următoarele valori limită de intrare: EMPTAB are o valoare de intrare EMPTAB are numărul maxim de valori de intrare ( ) EMPTAB are valori de intrare EMPTAB are o valoare de intrare DEPTTAB are numărul maxim de valori de intrare ( ) DEPTTAB are valori de intrare Departamentul cu volumul maxim de vânzări are un angajat Departamentul cu volumul maxim de vânzări are angajați Departamentul cu volumul maxim de vânzări nu are angajați Toate departamentele din DEPTTAB au o cantitate egală de vânzări Departamentul cu cea mai mare cantitate de vanzari ocupa prima pozitie in DEPTTAB Departamentul cu cea mai mare cantitate de vanzari ocupa ultima pozitie in DEPTTAB Un alt angajat ocupa prima pozitie in EMPTAB Un alt angajat ocupa ultimul post in EMRT LV Un alt angajat - manager Un alt angajat - nu un manager Un alt angajat nu este manager și are un salariu de , USD Un alt angajat nu este manager și are un salariu de , USD Un alt angajat nu este manager și are un salariu de , USD Valori limită de ieșire: ERRCODE= ERRCODE= ERRC DE = Salariul suplimentar este de , USD, care este maxim Următoarea condiție de testare se bazează pe ipoteza erorii Departamentul cu cea mai mare sumă de vânzări și fără angajați este urmat de un alt departament cu cea mai mare sumă de vânzări care are angajați pe lista sa Acest lucru se face pentru a determina dacă procesarea datelor de intrare a eșuat efectiv în cazul în care a fost generat un cod de eroare ERRCODE Din analiza celor de condiții enumerate mai sus, se poate observa că condițiile , și nu au nicio semnificație practică pentru construirea unui test Aceste condiții reprezintă situații care nu pot apărea În versiunea noastră, o astfel de presupunere este destul de acceptabilă, deși în cazul general este nesigură Următorul pas în construirea unui set de testare este să comparați restul de de condiții cu setul de testare existent (vezi Figura ) și să determinați care condiții la limită nu sunt încă acoperite de acesta Comparația arată că condițiile , , , , , , , , , și necesită o extindere a setului de testare deja existent prezentat în Fig Apoi, trebuie să proiectați teste suplimentare care să acopere aceste condiții limită O abordare posibilă este combinarea tuturor condițiilor cu testele existente (de exemplu, modificând într-un fel setul din Figura ) Dar nu este recomandat să se acționeze în acest fel, deoarece procedând astfel, se poate distruge cu neglijență caracterul complet al acoperirii combinatorii a condițiilor unui test deja existent Prin urmare, cel mai sigur mod de a construi un test este de a crea noi teste în plus față de cele prezentate în Figura , iar numărul de teste necesare pentru a acoperi condițiile limită ar trebui să fie minim Pe fig prezintă trei teste care îndeplinesc această cerință Testul acoperă condițiile , , , , , și , testul acoperă condițiile , , , iar testul acoperă condiția Deci, la construirea unui test acceptabil pentru modulul BONUS, a fost utilizată metoda de acoperire logică sau principiul cutiei albe, pe baza căruia testul prezentat în Fig , iar apoi pe principiu chipu black box au fost create teste suplimentare fig Test Ieșire estimată ■ ESIZE= DSIZE= EMPTAB DEPTTAB Ollie E D B IA , D , Da E D , D , Seltow E D , ERRCODE= ESIZE, DSIZE și DEPTTAB nu se modifică EMPTAB Ollie E D , Est E D Seltow E D , ESIZE= DSIZE=- EMPTRB DEPTTAB a \chif | M | z?g | gwya] | ooo,oo\ ERRCODE- ESIZE, DSIZE și DEPTTAB nu se modifică EMPTAB | Șef IMI D \ ,~ F] ESIZE- DS ZE = EMPTAB DEPTTAB Dole E D , REB , Ford E D , D , ERRCODE= ESIZE, DSIZE și DEPTTAB nu se modifică EMPTAB Dole E DS Ford E D , Orez Teste suplimentare pentru analiza valorilor limită pentru modul TESTARE IN PAS Implementarea procesului de testare unitară se bazează pe două considerente cheie: construirea unei suite de teste eficiente (discutate în capitolul anterior) și alegerea modului în care unitățile sunt combinate pentru a construi un program de lucru din ele A doua prevedere este foarte importantă, deoarece definește forma în care sunt scrise testele modulelor, tipurile de instrumente utilizate în testare, ordinea în care modulele sunt codificate și testate, costul generării testelor și costul depanării (de ex , localizarea și remedierea erorilor) În această secțiune, vom analiza două abordări pentru combinarea modulelor: testarea pas cu pas și monolitică, iar în următoarea, două opțiuni Aceasta este o abordare treptată: testare de jos în sus (de jos în sus) și testare de sus în jos (de sus în jos) Apare întrebarea: ce este mai bine - să testați fiecare modul separat și apoi, combinându-le, să formați un program de lucru sau fiecare modul pentru testare? Figura Exemplu de program cu șase module pentru a vă conecta la un set de module testate anterior? Prima abordare este de obicei numită metoda de testare monolitică sau metoda „big hit” de testare și construire a programului; a doua abordare este cunoscută ca metoda de testare sau de construire pas cu pas Ca exemplu, luați în considerare programul din fig Casetele reprezintă cele șase module de program (subrutine sau proceduri) Liniile arată ierarhia de control: modulul A apelează modulele B, C și D, modulul B apelează modulul E și așa mai departe În abordarea tradițională monolitică, testarea se efectuează după cum urmează În primul rând, sunt testate șase module incluse în program, fiecare fiind testat independent de celelalte În diferite condiții (procesare în lot sau mod interactiv) și numărul de executanți, modulele pot fi testate secvenţial sau în paralel Modulele sunt apoi combinate sau asamblate într-un program (de exemplu, prin editarea link-urilor) Testarea oricărui modul necesită un modul driver dedicat și unul sau mai multe module stub De exemplu, dacă modulul B este testat, primul lucru de făcut este să dezvoltați teste și apoi să scrieți un mic program care să ofere modulului B datele de testare de intrare necesare pentru a-l executa (rulați testul) (În acest scop, puteți utiliza În practica de programare, driverele sunt numite și module de depanare, iar stub-urile sunt numite și simulatoare - Notă ed De asemenea, driverul ar trebui să afișeze programatorului câteva informații despre rezultatele modulului B De asemenea, deoarece modulul B are un apel către modulul E, se recomandă să se realizeze un modul stub căruia să fie transferat controlul atunci când apelul către modulul E este executat , care este folosit în locul modulului E în timpul testării, primește și numele „E” și trebuie să imite funcțiile acestui modul După finalizarea testării tuturor celor șase module, acestea sunt asamblate într-un singur program Metoda de testare pas cu pas presupune că modulele nu sunt testate izolat unele de altele, ci sunt conectate unul câte unul pentru a efectua testul la un set de module testate anterior Numărul de implementări posibile ale metodei pas cu pas este mare, deci luarea în considerare a unei proceduri specifice pas cu pas pentru programul prezentat în Fig este încă prematur Întrebarea cheie este dacă testarea unui program ar trebui să înceapă de sus sau de jos Cu toate acestea, să lăsăm această întrebare până la următoarea secțiune și să presupunem că testarea începe de jos Inițial, puteți testa secvențial sau în paralel (de exemplu, trei persoane pot face acest lucru) modulele E, C și F În acest caz, va trebui să faceți un driver pentru fiecare modul; cioturile nu sunt necesare aici Următorul pas este testarea modulelor B și D, dar nu independent, ci împreună cu modulele E și, respectiv, F Cu alte cuvinte, pentru a testa modulul B, se dezvoltă un driver care include teste, iar perechea B-E este testată Procesul pas cu pas continuă până când ultimul modul, în acest caz modulul A, este conectat la setul de module testate Rețineți că această procedură poate fi dezvoltată și de sus în jos Deja în această etapă, putem face câteva generalizări: Testarea monolitică necesită multă muncă Pentru programul din fig , trebuie create cinci drivere și cinci stub-uri, având în vedere că modulul superior nu are nevoie de driver Testarea pas cu pas de jos în sus va necesita doar cinci drivere, iar de sus în jos, doar cinci stub-uri Reducerea costurilor cu forța de muncă se explică prin faptul că la testarea de sus în jos, modulele testate îndeplinesc funcțiile cioturi, iar la testarea de jos în sus - funcțiile driverelor În testarea pas cu pas, erorile în interfețele dintre module sunt detectate mai devreme, deoarece asamblarea programului începe mai devreme În schimb, în testarea monolitică, modulele nu se „văd” până în ultima fază a procesului de testare Depanarea programelor cu testare pas cu pas este mai ușoară Dacă există erori în interfețele dintre module, așa cum se întâmplă de obicei, acestea pot fi descoperite doar prin testare monolitică atunci când întregul program este construit În acest moment, este destul de dificil să localizați eroarea, deoarece poate fi localizată oriunde în program Dimpotrivă, cu testarea pas cu pas, erorile de acest tip sunt asociate în principal cu modulul care este conectat ultimul Rezultatele testului pas sunt mai perfecte De exemplu, la testarea modulului B, fie modulul A, fie modulul E este executat simultan (în funcție de faptul dacă testarea începe de sus sau de jos) Deși aceste module au fost deja testate temeinic înainte, utilizarea lor împreună cu modulul B va crea condiții noi și poate că unul dintre ele se va potrivi cu condiția care nu a fost luată în considerare în testarea lor de sine stătătoare Pe de altă parte, atunci când se testează o unitate în mod monolit, rezultatele sunt limitate doar la acea unitate Cu alte cuvinte, datorită faptului că în cazul testării în etape, modulele care au fost testate mai devreme sunt apoi folosite ca drivere sau stub-uri, acestea sunt supuse verificării suplimentare atunci când se execută testul modulului de depanat Consumul de timp de calculator pentru testarea monolitică este mai mic Dacă modulul A este testat folosind o abordare pas cu pas de jos în sus, atunci modulele B, C, D, E și, eventual, modulul F sunt executate simultan cu acesta, iar în cazul testării monolitice, numai modulul A însuși și stub-urile sunt executate în locul modulelor B, C și D Același lucru se întâmplă dacă se folosește o abordare de sus în jos pas cu pas: dacă modulul F este testat, atunci modulele A, B, C, D și E pot fi executat simultan, în timp ce în testarea monolitică numai modulul F însuși este executat și corespunzător ^ șoferul corespunzător Prin urmare, numărul de instrucțiuni de mașină executabile în timpul testării cu testarea pas cu pas este în mod clar mai mare decât în cazul testării monolitice Cu toate acestea, acest exces este compensat de faptul că testarea monolitică necesită mai multe stub-uri și drivere decât testarea în pas și, ca urmare, timpul mașinii este alocat dezvoltării acestor drivere și stub-uri h Utilizarea metodei monolitice oferă oportunități mari de organizare a muncii în paralel la faza inițială de testare (testarea tuturor modulelor simultan) Această prevedere poate fi importantă în implementarea proiectelor mari în care există multe module și mulți performeri, întrucât numărul de personal implicat în proiect este maxim în faza inițială În concluzie, observăm că itemii - demonstrează avantajele testării pas cu pas, iar itemii și arată dezavantajele acesteia Deoarece stadiul actual de dezvoltare a tehnologiei informatice tinde să reducă costul echipamentelor și să crească costul forței de muncă, consecințele erorilor în software-ul matematic sunt foarte grave, iar costul eliminării unei erori este cu atât mai mic cu cât aceasta este detectată mai devreme ; avantajele indicate la paragrafele - ies în prim-plan În același timp, prejudiciul cauzat de neajunsuri (punctele și ) este mic Toate acestea ne permit să concluzionam că este de preferat testarea în pas DESCĂRCARE ȘI ACTUALIZARE TESTARE Convinși de avantajele testării în etape față de testarea monolitică, explorăm două strategii posibile de testare: de sus în jos și de jos în sus Inainte de Această afirmație consecventă din punct de vedere logic se poate dovedi a fi incorectă în anumite condiții De exemplu, dacă timpul de numărare al fiecărui modul real depanat este de câteva minute sau mai mult, iar timpul mașinii pentru a dezvolta un driver sau un stub este de zeci de secunde, atunci se observă relația opusă Atunci când alegeți o metodă de testare pentru o anumită dezvoltare, trebuie să luați în considerare caracteristicile software-ului, disponibilitatea resurselor și cerințele pentru gradul de depanare a produsului finit; în aceste condiții, timpul mașinii nu este întotdeauna factorul dominant chiar și pentru o dezvoltare mare Notă ed Doar pentru a clarifica terminologia În primul rând, termenii testare de sus în jos, dezvoltare de sus în jos, proiectare de sus în jos sunt adesea folosiți în mod interschimbabil Într-adevăr, termenii „testare de sus în jos” și „dezvoltare de sus în jos” sunt sinonimi (în sensul că implică o anumită strategie în testarea și scrierea codului modulului), dar designul de sus în jos este un proces complet diferit și independent Un program proiectat de sus în jos poate fi testat atât de sus în jos, cât și de jos în sus În al doilea rând, dezvoltarea sau testarea de jos în sus este adesea echivalată cu testarea monolitică Această neînțelegere apare din faptul că începutul testării în sus este identic cu cel monolitic la testarea modulelor inferioare sau terminale Dar secțiunea anterioară a arătat că testarea de jos în sus este de fapt o strategie pas cu pas Acum că este evident că ambele strategii sunt incrementale, nu vom discuta despre avantajele abordării incrementale; Luați în considerare diferența dintre strategiile de sus în jos și de jos în sus Testare descendentă Testarea de sus în jos începe cu modulul de sus, principal al programului Nu există o procedură strictă și corectă pentru conectarea următorului modul testat secvenţial Singura regulă care trebuie urmată la alegerea următorului modul este că acesta trebuie să fie unul dintre modulele apelate de modulul care a trecut anterior testul Pentru a ilustra această strategie, luăm în considerare Fig Programul descris pe acesta constă din douăsprezece module A-L Să presupunem că modulul J conține operații de citire din memoria externă, iar modulul I conține operațiuni de scriere Primul pas este testarea modulului A Pentru a realiza acest lucru, trebuie să scrieți module stub care înlocuiesc modulele B, C și D Din păcate, funcțiile îndeplinite de modulele stub sunt adesea înțelese greșit Deci, uneori puteți auzi că „stub-ul ar trebui să scrie doar un mesaj care să menționeze: „modulul conectat” sau „suficient to stub” Lushka a existat fără a lucra deloc” În cele mai multe cazuri, aceste afirmații sunt greșite Când modulul A apelează modulul B, A presupune că B lucrează, adică modulul A primește rezultatele muncii modulului B (de exemplu, sub forma valorilor variabilelor de ieșire) Când este modulul B Orez Exemplu de program cu douăsprezece module pur și simplu returnează controlul sau aruncă un mesaj de eroare fără a transmite niște rezultate semnificative lui A, modulul A nu funcționează corect din cauza erorilor din modulul în sine, ci din cauza unei nepotriviri a modulului stub cu acesta Mai mult, rezultatul poate fi nesatisfăcător dacă răspunsul modulului stub nu se modifică în funcție de condițiile de testare De exemplu, să presupunem că doriți să scrieți un stub care înlocuiește un program rădăcină pătrată, un program de căutare în tabel sau un cititor de înregistrări corespunzător Dacă stub-ul returnează întotdeauna același rezultat fix în loc de o anumită valoare pe care apelantul se așteaptă la acel apel anume, atunci apelantul fie va eșua (de exemplu, bucla) fie va produce o valoare de ieșire nevalidă Prin urmare, crearea modulelor stub nu este o sarcină trivială Când se discută despre metoda de testare de sus în jos, un alt punct este adesea trecut cu vederea, și anume, forma în care testele sunt prezentate într-un program În exemplul nostru, întrebarea este cum trebuie depuse testele modulul A? Răspunsul la această întrebare nu este în întregime evident, deoarece modulul superior dintr-un program tipic nu primește el însuși intrare și nu efectuează I/O Modulul superior (în cazul nostru, modulul A) primește date prin unul sau mai multe stub-uri Pentru a ilustra, să presupunem că modulele B, C și D îndeplinesc următoarele funcții: Orez Al doilea pas în testarea descendentă B - Obține un rezumat al fișierului suport; C - stabilește dacă starea de fapt săptămânală corespunde nivelului stabilit; D - generează un raport final pentru săptămână Într-un astfel de caz, testul pentru A este un rezumat al fișierului suport primit de la stub-ul B Stub-ul D conține instrucțiuni care își imprimă intrarea la o imprimantă sau la un terminal pentru a permite analiza rezultatelor trecerii fiecărui test Există o altă problemă cu acest program Deoarece modulul A apelează modulul B probabil o dată, trebuie să decidem cum să trecem mai multe teste lui A O soluție este să faci mai multe versiuni ale stub-ului în loc de B, fiecare cu un caz de testare fix Apoi, pentru a utiliza orice suită de testare, trebuie să executați programul de mai multe ori și de fiecare dată cu o nouă versiune a modulului stub care înlocuiește B O altă soluție este să scrieți seturi de testare în memoria externă, să le citiți cu un stub și să transferați le la modulul A În cazul general, crearea unui stub poate fi o sarcină mai dificilă decât în exemplul de mai sus În plus, este adesea necesar, datorită caracteristicilor programului, să se furnizeze unității testate date din mai multe stub-uri care înlocuiesc modulele de nivel inferior; de exemplu, un modul poate primi date de la mai multe module pe care le apelează După finalizarea testării modulului A, unul dintre stub-uri este înlocuit cu un modul real și se adaugă stub-urile necesare acestui modul De exemplu, în fig arată următoarea versiune a programului După testarea modulului superior (capul), testarea este efectuată în diverse secvențe Deci, dacă toate modulele sunt testate secvenţial, atunci sunt posibile următoarele opţiuni: ABCDEFGHIJKL AB EF JCGKDHL I ADHIKLCGBFJE ABFJDIECGKHL Când testarea este efectuată în paralel, pot apărea alte secvențe De exemplu, după testarea modulului A, un programator poate testa secvența A - B, altul - A - C, a treia - A - D În principiu, nu există o astfel de secvență care ar fi preferată, dar se recomandă să se respecte la două reguli de bază: Dacă programul are părți critice într-un anumit sens (eventual modulul G), atunci este recomandabil să alegeți o secvență care să includă aceste părți cât mai curând posibil Un modul critic poate fi un modul complex, un modul cu un nou algoritm sau un modul cu un număr semnificativ de erori așteptate (modul predispus la erori) Modulele care includ operațiuni I/O ar trebui, de asemenea, incluse în secvența de testare cât mai devreme posibil Oportunitatea primei reguli este evidentă, în timp ce a doua ar trebui discutată în continuare Amintiți-vă că atunci când proiectați stub-uri, apare o problemă că unele dintre ele trebuie să conțină teste, în timp ce altele trebuie să organizeze ieșirea rezultatelor pentru imprimare sau către terminal Dacă la program este conectat un modul real care conține operații de intrare, prezentarea testelor este mult simplificată Forma de prezentare a acestora devine identică cu cea utilizată într-un program real pentru introducerea datelor (de exemplu, dintr-un fișier auxiliar sau intrare de la un terminal) În mod similar, dacă plug-in-ul conține funcțiile de ieșire ale programului, atunci nu este nevoie de stub-uri care înregistrează Orez Stare intermediară în testarea descendentă rezultatele testului Fie, de exemplu, modulele J și I îndeplinesc funcții de intrare-ieșire, iar G să fie o funcție critică; atunci secvența pas cu pas ar putea fi după cum urmează: ABFJDICGEKHL iar după al șaselea pas devine așa cum se arată în Fig La atingerea stadiului prezentat în Fig , prezentarea testelor și analiza rezultatelor testelor sunt mult simplificate Există beneficii suplimentare În acest moment, există deja o versiune de lucru a structurii programului care efectuează operații reale I/O, în timp ce unele dintre funcțiile interne sunt imitate de stub-uri Această versiune de lucru vă permite să identificați erorile și problemele asociate cu organizarea interacțiunii cu o persoană; oferă o oportunitate de a demonstra programul utilizatorului, arată clar că întregul proiect este testat și pentru unii este, de asemenea, o creștere pozitivă a moralului Toate acestea, fără îndoială dar, meritele unei strategii de testare de sus în jos Cu toate acestea, testarea de sus în jos are o serie de dezavantaje serioase Fie ca starea programului testat să corespundă cu cea prezentată în Fig Următorul pas este înlocuirea stub-ului cu modulul H Pentru a testa acest modul, trebuie să proiectați (sau să le fi proiectat mai devreme) teste conform regulilor prezentate mai devreme în acest capitol Rețineți că toate testele trebuie prezentate ca date reale introduse prin modulul J Acest lucru creează două probleme În primul rând, există module intermediare (F, B, A și D) între modulele H și J, astfel încât este posibil să nu fie posibilă trecerea textului către modul care ar corespunde fiecărei situații descrise anterior la intrarea modulului H Pentru exemplu, dacă H este un modul BONUS prezentat în fig , se poate întâmpla ca, din cauza modulului intermediar D, să fie imposibil să se aplice toate cele șapte teste prezentate în Fig la intrarea modulului H și În al doilea rând, chiar dacă este posibil să treci toate testele, atunci, din cauza „distanței” dintre modulul H și punctul de intrare în program, apare o sarcină intelectuală destul de dificilă - să se estimeze care ar trebui să fie datele de la intrarea modulului J astfel încât să corespundă încercărilor solicitate ale modulului N A treia problemă este că rezultatele execuției testului sunt afișate de un modul care se află destul de departe de modulul care este testat în prezent Prin urmare, stabilirea unei corespondențe între ceea ce este arătat și ceea ce se întâmplă de fapt în modul este destul de dificilă și uneori pur și simplu imposibilă Să presupunem că adăugăm la circuitul din fig modulul E Rezultatele fiecărui test sunt determinate prin analiza ieșirilor modulului I, dar din cauza modulelor intermediare dintre modulele E și I, este dificil să se recupereze ieșirile reale ale modulului E (adică rezultatele pe care acesta le trece) la modulul B) În testarea de sus în jos, pot apărea încă două probleme în legătură cu organizarea implementării acesteia Unii programatori cred că testarea poate fi combinată cu proiectarea programului De exemplu, dacă programul prezentat în Fig , atunci s-ar putea să aveți impresia că, după ce ați proiectat primele două niveluri, ar trebui să mergeți la dezvoltarea și testarea modulelor A și B, C și D și dezvoltarea modulelor de nivel inferior După cum se menționează în [ ], o astfel de soluție nu este rezonabilă Proiectarea programului este un proces iterativ, adică atunci când se creează module care ocupă nivelul inferior în structura programului, poate fi necesar să se facă modificări la modulele de nivel superior Dacă modulele de nivel superior sunt deja codificate și testate, atunci cel mai probabil aceste modificări nu vor fi făcute, iar soluția adoptată anterior nu cea mai bună va avea o viață lungă Ultima problemă este că, în practică, este obișnuit să treceți la testarea următorului modul înainte de testarea celui precedent Acest lucru se datorează a două motive: în primul rând, este dificil să inserați date de testare în modulele stub și, în al doilea rând, modulele de nivel superior consumă resursele modulelor de nivel inferior Din fig Figura arată că testarea modulului A poate necesita mai multe versiuni ale stub-ului modulului B Programatorul care testează programul decide de obicei: „Nu voi testa imediat modulul A - acum aceasta este o sarcină dificilă Când conectez modulul J, va deveni mai ușor să prezint teste, iar apoi voi reveni la modulul de testare A ” Desigur, singurul lucru important aici este să nu uitați să verificați restul modulului când trebuia să fie făcut O problemă similară apare deoarece modulele de nivel superior solicită și resurse pentru utilizarea modulelor de nivel inferior (de exemplu, fișiere deschise) Este uneori dificil de determinat dacă aceste resurse au fost solicitate corect (de exemplu, dacă atributele de deschidere a fișierului sunt corecte) până când începe testarea modulelor de nivel inferior care le folosesc Testare în amonte Luați în considerare o strategie de testare pas cu pas de jos în sus În multe privințe, testarea ascendentă este opusul testării descendente; Avantajele testării de sus în jos devin dezavantaje ale testării de jos în sus și invers, dezavantajele testării de sus în jos devin avantaje ale testării de jos în sus Având în vedere acest lucru, să discutăm pe scurt strategia de testare de jos în sus \- ?ai er\ Orez Stare intermediară în testarea ascendentă Această strategie presupune începerea testării de la module terminale (adică module care nu apelează alte module) Ca și până acum, nu există o astfel de procedură de alegere a modulului care urmează să fie testat în pasul următor, căruia i-ar fi acordat preferință Singura regulă este că următorul modul apelează modulele deja testate Dacă revenim la fig , primul pas ar trebui să fie testarea unora sau a tuturor modulelor E, J, G, K, L și I în serie sau în paralel Fiecare dintre acestea necesită un modul driver diferit, adică un modul care conține date de testare fixe, apelează modulul testat și afișează ieșirea (sau compară ieșirea reală cu ieșirea așteptată) Spre deosebire de stub-uri, un driver nu trebuie să aibă mai multe versiuni, așa că poate apela secvenţial unitatea testată de mai multe ori În cele mai multe cazuri, driverele sunt mai ușor de dezvoltat decât stub-urile Ca și în cazul precedent, secvența de testare este afectată de natura critică a modulului Dacă decidem că modulele D și F sunt cele mai critice, atunci starea intermediară va corespunde cu Fig Următorii pași ar putea fi să testați modulul E, apoi modulul B și să combinați B cu modulele E, F, J testate anterior Dezavantajul strategiei luate în considerare este că lipsește conceptul de construire a structurii programului de lucru într-un stadiu incipient al testării Într-adevăr, programul de lucru nu există până când nu este adăugat ultimul modul (în exemplu, modulul A), iar acesta este deja un program terminat Deși funcțiile I/O pot fi testate înainte ca întregul program să fie construit (modulele I/O utilizate prezentată în fig ), beneficiile proiectării timpurii a programului sunt în scădere Nu există probleme asociate cu imposibilitatea sau dificultatea de a crea toate situațiile de testare, care sunt tipice pentru testarea de sus în jos Driverul ca instrument de testare este aplicat direct pe modulul testat, nu există module intermediare de luat în considerare Analizând alte probleme care apar în testarea de sus în jos, se poate observa că în testarea de jos în sus este imposibil să se ia o decizie nerezonabilă de a combina testarea cu proiectarea programului, deoarece testarea nu poate începe până când modulele de nivel inferior nu sunt proiectate De asemenea, nu există nicio problemă cu testarea unui modul incomplet când treceți la testarea altuia, deoarece testarea de jos în sus care utilizează mai multe versiuni ale „stub” nu are problema de a prezenta datele de testare Comparaţie Din păcate, atunci când se compară strategiile de testare de sus în jos și de jos în sus, nu se pot opune între ele, așa cum sa făcut atunci când se compară abordările pas cu pas și monolitice În tabel Figura prezintă dezavantajele și avantajele lor relative (cu excepția avantajelor generale ca metode de testare pas cu pas) Primul avantaj al fiecăreia dintre metode ar putea fi un factor decisiv, dar este greu de spus unde sunt mai multe dezavantaje: în modulele de nivel superior sau în modulele de nivel inferior ale unui program tipic Prin urmare, atunci când alegeți o strategie, este indicat să cântăriți toate punctele din tabel luând în considerare caracteristicile unui anumit program Pentru programul exemplu, al patrulea dezavantaj al testării de sus în jos este de mare importanță Având în vedere acest dezavantaj și faptul că instrumentele de depanare reduc nevoia de drivere, dar nu de stub-uri, ar trebui să se prefere o strategie de testare de jos în sus În concluzie, observăm că strategiile de testare de sus în jos și de jos în sus considerate nu sunt singurele posibile cu o abordare pas cu pas În [ ], sunt luate în considerare încă trei variante ale strategiei de testare Tabelul Comparație între testarea de sus în jos și de jos în sus Avantaje • Dezavantaje Testare descendentă Are avantaje, Are nevoie de dezvoltare dacă erorile sunt principalele module obvat-stubs împreună în vârful programului Reprezentarea unui test despre - Module stub des devine mai ușor după conectare, se dovedește a fi mai dificil, funcții de intrare - decât pare la început ieșire Formarea timpurie Înainte de aplicarea funcţiilor Structura programului I/O poate fi vă permite să-l desfășurăm de- dificil să reprezinte cei demonstrarea datelor utilizatorului în stub lu si serveste ca moral ki stimulent Creștere Poate fi dificil sau imposibil să se creeze condiții de testare Este mai dificil de evaluat rezultatele testelor Este permisă posibilitatea formării unei idei de combinare a testării și proiectării Stimulată de testarea incompletă a unor module, testarea acesteia Are avantaje, Are nevoie de dezvoltare dacă erorile sunt în principal module-driver obvat deodată în modulul de nivel inferior Programul în ansamblu Mai ușor de creat cazuri de testare condiții întreg nu există înainte Este mai ușor de evaluat rezultatul - atâta timp cât nu este adăugat - articole in ultimul modul EXECUTAREA TESTEI Execuția testului este etapa finală a testării unitare Mai jos este un set specific de îndrumări și îndrumări care ar trebui urmate în această etapă Dacă execuția testului dă rezultate care nu se potrivesc cu cele dorite, atunci aceasta înseamnă că fie modulul are o eroare, fie rezultatele așteptate sunt incorecte (o eroare în test) Pentru a elimina acest tip de neînțelegere, trebuie să verificați cu atenție suita de teste (testele „test”) Utilizarea instrumentelor automate poate reduce complexitatea procesului de testare De exemplu, există instrumente care vă permit să scăpați de nevoia de șoferi Instrumentele de analiză a fluxului fac posibilă numerotarea rutelor din program, identificarea instrucțiunilor neexecutabile și găsirea locurilor în care sunt utilizate variabilele înainte de a li se atribui o valoare La pregătirea modulelor de testare, este recomandabil să revizuim din nou principiile psihologice și economice discutate în Cap Amintiți-vă că, așa cum sa arătat mai devreme, o parte necesară a suitei de teste este o descriere a rezultatelor așteptate Când executați un test, ar trebui să acordați atenție efectelor secundare, de exemplu, dacă un modul face ceva ce nu ar trebui să facă În cazul general, o astfel de situație este dificil de detectat, dar uneori efectele secundare pot fi detectate prin verificarea nu numai a variabilelor de ieșire așteptate, ci și a altora a căror stare nu ar trebui să se schimbe în timpul testării De exemplu, testul din Fig nu trebuie să modifice valorile variabilelor ESIZE, DSIZE și DEPTTAB Prin urmare, în timpul execuției sale, împreună cu rezultatele așteptate, este necesară verificarea acestor variabile În timpul testării modulelor, există și probleme psihologice asociate cu personalitatea testatorului Este bine ca programatorii să schimbe module, astfel încât să nu fie nevoiți să le testeze pe ale lor Astfel, programatorul care a realizat modulul apelant este un bun candidat pentru testarea modulului apelat Rețineți că acest lucru se aplică numai pentru testare, nu pentru depanare, care ar trebui să fie făcută întotdeauna de autorul modulului Nu următorul aruncați rezultatele testelor; prezentați-le în așa fel încât să le puteți reutiliza în viitor Fiți conștienți de posibilitatea unei intuiții eronate (vezi Figura ) Dacă se găsesc un număr mare de erori într-un subset de module, atunci este probabil ca acele module să conțină un număr și mai mare de erori nedetectate Astfel de module ar trebui să facă obiectul unor teste suplimentare; este chiar de dorit să controlați sau să vizualizați suplimentar textul acestora În cele din urmă, trebuie amintit că sarcina testării nu este de a demonstra funcționarea corectă a modulelor, ci de a identifica erorile LITERATURĂ Myers GJ Compozit/Design structurat New York, Van Nost-rand Reinhold, Fiabilitatea software-ului Myers GJ: principii și practici New York, Wiley-Interscience, Traducere rusă: Myers G Software Reliability M , Mir, CAPITOLUL TESTARE A COMPLEXELOR SOFTWARE Sfârșitul testării modulului nu înseamnă că testarea programului este finalizată De fapt, procesul de testare abia începe, mai ales dacă programul este mare sau este un produs software Această idee este confirmată de următoarea definiție a unei erori software [ ]: un program are o eroare dacă execuția sa nu corespunde așteptărilor utilizatorului Este clar că efectuarea chiar și a unei încercări absolut complete a unui modul nu ar garanta în niciun fel detectarea tuturor erorilor software (având în vedere definiția de mai sus) Acesta este unul dintre motivele pentru care trebuie dezvoltată o formă de testare suplimentară Un alt motiv este legat de descrierea preliminară a apariției erorilor software Faptul este că dezvoltarea de software este în mare măsură un proces de transfer de informații despre programul final și de traducere a acestor informații dintr-o formă în alta [ ] În plus, marea majoritate a erorilor software sunt determinate de defecte în organizarea muncii, de înțelegere reciprocă insuficientă și de distorsiuni în procesul de transfer și traducere a informațiilor Această vedere a dezvoltării software este ilustrată în Fig , care prezintă modelul ciclului de dezvoltare a produsului software * Procesul de dezvoltare poate fi împărțit în șapte etape: În sistemul de standardizare de stat sovietic, se stabilește un set ușor diferit de etape și etape de dezvoltare Prin urmare, atât terminologia, cât și conținutul etapelor de dezvoltare date în această carte nu trebuie considerate ca fiind general acceptate Nevoile viitorului utilizator al programului în curs de dezvoltare sunt concretizate într-un document care descrie un set de cerințe pentru produsul dezvoltat Evaluând fezabilitatea și costul, rezolvarea cerințelor conflictuale, prioritizarea dezvoltării și livrării, aceste cerințe sunt traduse în obiective bine definite Pe baza acestor obiective, se creează o specificație detaliată și precisă a produsului software final, iar produsul în sine este considerat o cutie neagră și numai interfețele și interacțiunile sale cu lumea exterioară (de exemplu, cu utilizatorul final) sunt luat in considerare Această specificație se numește externă Proiectarea sistemului se realizează dacă produsul software este un sistem* (de exemplu, sistem de operare, sistem de control al traficului aerian, sistem de gestionare a bazelor de date, sistem de evidență a personalului) și nu un program (de exemplu, compilator, program de salarizare, format de text) La acest pas, sistemul este defalcat în programe, componente sau subsisteme individuale, iar interfețele acestora sunt definite Structura programului este concepută prin specificarea (stabilirea) funcției fiecărui modul, a structurii ierarhice a tuturor modulelor și a tuturor interfețelor dintre module Se elaborează o specificație detaliată și precisă prin definirea interfeței și a funcției fiecărui modul În unul sau mai mulți subpași, specificația interfeței modulului este tradusă în algoritmul fiecărui modul scris în limba sursă Cu alte cuvinte, cerințele justifică de ce și se aplică necondiționat În același timp, experiența și practica dezvoltării de software în Statele Unite, reflectate aici, prezintă un interes indubitabil În prezent, se lucrează mult pentru a aduce standardele existente în conformitate cu practica modernă de creare a produselor software, atât în conținut, cât și în terminologie - Notă ed Pentru toate exemplele de mai sus, cu excepția primului, ar fi mai corect să spunem „este o parte integrantă a sistemului”, deoarece sistemele corespunzătoare includ și echipamente și personal În practica internă, în astfel de cazuri, se utilizează termenul „produs” sau „produs software”, spre deosebire de termenul „program” - Notă ed cerințe favoarea supremă a unui corp Specificație externă Pro-comandă Examinare Goluri sisteme Proiect de structură a programului ^ Specificații mod Hlerface/ C Cod sursă j Orez Procesul de dezvoltare software Pro-comandă Examinare Examinare Pro-comandă Proiectarea sistemului Specificații de interfață mod> Proiect de structură a programului Sursă Orez Proces de dezvoltare cu verificări intermediare fExternă specificație Examinare programul este necesar, obiectivele definesc ce ar trebui să facă programul și cât de bine ar trebui să o facă, specificațiile externe oferă o imagine exactă a programului de către utilizatorii săi, iar documentația asociată procesului secvenţial descris mai sus arată la toate nivelurile de detaliază modul în care este construit programul L Descrierea preliminară de mai sus a procesului de dezvoltare include transferul, înțelegerea și traducerea informațiilor de la pas la pas, precum și ipoteza că cel mai mare număr de erori software are loc datorită transformării pas cu pas a informațiilor Există trei metode suplimentare pentru prevenirea și/sau detectarea acestor erori Prima dintre ele se bazează pe creșterea clarității procesului de dezvoltare în sine, ceea ce va evita apariția multor erori A doua metodă este introducerea la sfârșitul fiecărui proces (etapă) a unui pas de verificare separat, care are ca scop localizarea celui mai mare număr de erori înainte de a trece la următorul proces (pas) Această metodă este ilustrată în Fig De exemplu, o specificație externă este verificată prin compararea acesteia cu rezultatul etapei anterioare (un raport care conține o descriere a obiectivelor), iar fiecare eroare găsită este returnată procesului de dezvoltare a specificațiilor externe (pe pas) pentru eliminare Metode de verificare a testului inițial și revizuirea lui end-to-end, discutate în Cap sunt utilizate în etapa de verificare la sfârșitul celui de-al șaptelea proces A treia metodă se concentrează pe procese specifice de cercetare În practica internă, cerințele pentru software (SW) sunt formulate în termenii de referință pentru produs, în care software-ul este inclus ca parte integrantă; obiectivele sunt indicate în termenii de referință pentru software O specificație externă a cerințelor nu este compilată ca document separat, dar documentele sau secțiunile relevante sunt furnizate ca parte a proiectului și a proiectului tehnic Informațiile pe care autorul își propune să le includă în proiectarea sistemului reprezintă conținutul principal al proiectului tehnic Proiectul de structură a programului și specificațiile interfeței modulului sunt documentație intermediară a proiectului de lucru În același timp, autorul subliniază pe bună dreptate necesitatea urgentă de a înregistra toate aceste informații sub formă de documente agreate de dezvoltatori* și aprobate de proiectantul șef (și pentru termenii de referință, proiectele și proiectele tehnice - și de către documentele clientului - Notă ed concentrându-se pe procese specifice de dezvoltare, adică concentrează fiecare proces de testare pe orice etapă a traducerii, în urma căreia Orez Relația dintre procesele de dezvoltare și testare vaniya clasa de eroare divizată Această metodă este ilustrată în Fig Ciclul de testare aici este structurat în modelul ciclului de dezvoltare prezentat în figură Astfel, este necesar să se poată stabili o corespondență unu-la-unu între procesele de dezvoltare și testare De exemplu, scopul testării modulelor este de a găsi inconsecvențe între modulele programului și specificațiile interfeței acestora, scopul testării funcționale este de a arăta că un program nu respectă specificațiile sale externe, scopul testării sistemului este de a demonstra inconsecvența un produs software cu obiectivele sale originale Avantajele structurii descrise sunt că evită testarea redundante neproductive și elimină posibilitatea unei întregi clase de erori De exemplu, în această metodă, testarea sistemului se concentrează pe o anumită clasă de erori (realizate la traducerea obiectivelor într-o specificație externă), iar caracteristicile acesteia sunt măsurate în raport cu un anumit tip de documentație creat în timpul procesului de dezvoltare Această abordare diferă semnificativ de „testarea întregului sistem” prea simplistă, care uneori se limitează la simpla repetare a testelor create în etapele anterioare După cum sa menționat deja, formele de testare a pachetelor software (Figura ) sunt cele mai aplicabile produselor software (programe scrise în baza unui contract sau programe destinate utilizării generale; spre deosebire de programele experimentale sau de programele operate de autorul acestora) Programele care nu sunt un produs, de obicei, nu au cerințe și obiective formale; pentru ei, testul funcțiilor parțialului este singurul test de nivel superior În plus, nevoia de testare de nivel superior crește pe măsură ce dimensiunea programului crește Motivul pare să fie că raportul dintre erorile de proiectare (erori făcute la începutul procesului de dezvoltare) și erorile de codare este mult mai mare în programele mari decât în programele mici Rețineți că secvența proceselor de testare (verificare) prezentată în Fig nu coincide neapărat cu succesiunea lor în timp i/ - VG / Z FINANȚE ȘI S ІDTISTIKD